Saturday, May 31 2008
802.11n - The official delivery of pipe dreams
The IEEE's 802.11n standard is supposed to bring high speed wireless to the masses.
It's been in draft longer than most can remember, and from the schedule it appears that it won't be out of draft release and make it to a final specification until Dec 2009.
This is from a working party that was setup in January 2004! 
Sure there was a rival groups in the early days, but as of July 2005 these rivals (TGn Sync, WWiSE, and MITMOT) all agreed to merge their proposals into the TGn draft.
Last month we saw Draft 4 of the specification approved, and there is already talk of a Draft 5... how many before we get something into our hands?
Sure, there is a bunch of 'Draft 2.0' 802.11n devices on the market. It's risky business deploying one now. Why?
Many believe it will be the silver bullet for networking, with the promise of delivering 600Mbps. Many read that as 'data throughput' - that's not the case, it's raw bit-rate.
How many people to you currently speak to that use an 802.11g network whinge that they aren't seeing 54Mbps transfers?
Expect anywhere between 30-70Mbps in real world data-transfer rates.
Many have moved their cordless phones from the overburdened 2.4Ghz spectrum up to the 5Ghz area. (Just look at any new cordless phone -- most are shipping in this space). 802.11n will operate in both the the crowded 2.4Ghz space and the 5Ghz range.
Expect to see the same issues we saw when 2.4Ghz wireless networks first came out with a range of devices interfering with the 802.11n network. (on either 2.4Ghz or 5Ghz).
MIMO (multiple input, multiple output) does help somewhat, in extending the quality, range and provides multiple streams.
The draft allows for up to 4 antennas on either end, but you'll be lucky to see one of these. Expect dual antennas to be the norm.
In addition, high-throughput will require high performing CPUs (particularly if you have encryption enabled -- which should be unless you want to be wifi-jacked). Home wireless network routers are notorious for having underpowered CPUs... whilst they will get a little jump in grunt, expect them to falter if attempting several large data transfers at the same time.
It appears 802.11n routers will be a mine-field for some time for consumers, there are loads of options and those cheaper ones are likely to miss the bells and whistles... watch out for the cheapies that can't do both bands. Many are working solely in the 2.4Ghz range. Most of those on the market presently are only Draft-2.0 models, so they are quite a fair way from the 'final spec' (We know of 5 drafts at least prior to the final spec).
Ars Technica has a great review on current 802.11n routers. What they have to say doesn't suprise me. These are speeds all running in 802.11n mode and show the average of UDP/TCP throughput results at multiple locations:
For those Aussies wonder what the feet is in metres (well it was a US review).
1 metre ~= 3.28 feet. On the flip side, 1 foot ~= 30.48cms
So these results were measured at: 60.96cms, 7.62 metres, and 10.67 metres. Nothing out of the ordinary and actually relatively close for at least the first two. If you were < 1 metre away, just plug in an Ethernet cable!
One thing 802.11n will deliver is supposedly better range. so those struggling with dropouts on a 802.11g network may like the upgrade... though it will come at a cost. Don't expect the devices to come cheap. A 'decent' 802.11n device currently costs upwards of $200USD.... plus adding in all the cards you'll need, you could be up for some serious dollars.
From all reports if you want the range and speed - get the 5.0Ghz models.. though if it doesn't support 2.4Ghz you won't have backwards compatibility with 802.11g devices.
You will also notice most currently advertise 270Mbps or 110Mbps..... it's no where near real-world results. I would love to see one of these manufacturers demonstrate their delivery of these speeds, to date -- we haven't seen anything near them. Advertising raw bit speed is also misleading and these makers know it... they are aware when people look at speeds they normally are looking at 'real world' speed performances. I expect more outrageous claims to be made and the infamous 600Mbps will soon start to be sprouted. Realistically on a '600Mbps device' -- don't expect anything beyond 80Mbps. See that Ethernet cable isn't looking that old at all.
Me, I'll stick with 802.11g for the time being.. . I only use it currently to get to the Wii and the MythTV box. Occassionally I might use it for our laptops or visitors (if I can't be bothered running an Ethernet cable from the switch).
I'm laying Gigabit Ethernet on Cat6 throughout my new house (48 ports baby! ), and expect that all bar the Wii will be on that.
For streaming High Definition Video, don't expect your sparkling new 802.11n device to handle it, or if it does, don't expect multiple streams.
For a specification that been in the thinking tank now for 4 years, the current speeds are pretty disappointing.
It's been in draft longer than most can remember, and from the schedule it appears that it won't be out of draft release and make it to a final specification until Dec 2009.
This is from a working party that was setup in January 2004! Sure there was a rival groups in the early days, but as of July 2005 these rivals (TGn Sync, WWiSE, and MITMOT) all agreed to merge their proposals into the TGn draft.
Last month we saw Draft 4 of the specification approved, and there is already talk of a Draft 5... how many before we get something into our hands?
Sure, there is a bunch of 'Draft 2.0' 802.11n devices on the market. It's risky business deploying one now. Why?
- Being at 'draft' status each manufacturer has a different interpretation of the standard. This can mean that different manufacturers equipment is unlikely to work well (if at all), in addition different releases from the same manufacturer has no guarantee of interoperbility
- There is no guarantee that these devices (wireless cards, embedded chips and Access Points) will be upgradeable to the final specification.
- Not all the details of the specification have been sorted out (thus the draft). You're likely to run into some 'interesting' issues.
Many believe it will be the silver bullet for networking, with the promise of delivering 600Mbps. Many read that as 'data throughput' - that's not the case, it's raw bit-rate.
How many people to you currently speak to that use an 802.11g network whinge that they aren't seeing 54Mbps transfers?
Expect anywhere between 30-70Mbps in real world data-transfer rates.
Many have moved their cordless phones from the overburdened 2.4Ghz spectrum up to the 5Ghz area. (Just look at any new cordless phone -- most are shipping in this space). 802.11n will operate in both the the crowded 2.4Ghz space and the 5Ghz range.
Expect to see the same issues we saw when 2.4Ghz wireless networks first came out with a range of devices interfering with the 802.11n network. (on either 2.4Ghz or 5Ghz).
MIMO (multiple input, multiple output) does help somewhat, in extending the quality, range and provides multiple streams.
The draft allows for up to 4 antennas on either end, but you'll be lucky to see one of these. Expect dual antennas to be the norm.
In addition, high-throughput will require high performing CPUs (particularly if you have encryption enabled -- which should be unless you want to be wifi-jacked). Home wireless network routers are notorious for having underpowered CPUs... whilst they will get a little jump in grunt, expect them to falter if attempting several large data transfers at the same time.
It appears 802.11n routers will be a mine-field for some time for consumers, there are loads of options and those cheaper ones are likely to miss the bells and whistles... watch out for the cheapies that can't do both bands. Many are working solely in the 2.4Ghz range. Most of those on the market presently are only Draft-2.0 models, so they are quite a fair way from the 'final spec' (We know of 5 drafts at least prior to the final spec).
Ars Technica has a great review on current 802.11n routers. What they have to say doesn't suprise me. These are speeds all running in 802.11n mode and show the average of UDP/TCP throughput results at multiple locations:
| Device | 2 feet | 25 feet | 35 feet |
|---|---|---|---|
| Apple AirPort Extreme @ 2.4Ghz | 22.75Mbps | 25.15Mbps | 17.80Mpbs |
| Apple AirPort Extreme @ 5.0Ghz | 44.30Mbps | 34.20Mbps | 12.65Mpbs |
| Netgear RANGEMAX Next Wireless Router | 28.48Mbps | 24.83Mbps | 5.39Mpbs |
| D-Link XtremeN Wireless N Gigabit Router | 56.10Mbps | 17.42Mbps | FAIL! |
| Linksys Wireless-N Gigabit Router with Storage Link | 44.37Mbps | 20.10Mbps | 10.70Mbps |
For those Aussies wonder what the feet is in metres (well it was a US review).
1 metre ~= 3.28 feet. On the flip side, 1 foot ~= 30.48cms
So these results were measured at: 60.96cms, 7.62 metres, and 10.67 metres. Nothing out of the ordinary and actually relatively close for at least the first two. If you were < 1 metre away, just plug in an Ethernet cable!
One thing 802.11n will deliver is supposedly better range. so those struggling with dropouts on a 802.11g network may like the upgrade... though it will come at a cost. Don't expect the devices to come cheap. A 'decent' 802.11n device currently costs upwards of $200USD.... plus adding in all the cards you'll need, you could be up for some serious dollars.
From all reports if you want the range and speed - get the 5.0Ghz models.. though if it doesn't support 2.4Ghz you won't have backwards compatibility with 802.11g devices.
You will also notice most currently advertise 270Mbps or 110Mbps..... it's no where near real-world results. I would love to see one of these manufacturers demonstrate their delivery of these speeds, to date -- we haven't seen anything near them. Advertising raw bit speed is also misleading and these makers know it... they are aware when people look at speeds they normally are looking at 'real world' speed performances. I expect more outrageous claims to be made and the infamous 600Mbps will soon start to be sprouted. Realistically on a '600Mbps device' -- don't expect anything beyond 80Mbps. See that Ethernet cable isn't looking that old at all.
Me, I'll stick with 802.11g for the time being.. . I only use it currently to get to the Wii and the MythTV box. Occassionally I might use it for our laptops or visitors (if I can't be bothered running an Ethernet cable from the switch).
I'm laying Gigabit Ethernet on Cat6 throughout my new house (48 ports baby!
), and expect that all bar the Wii will be on that.For streaming High Definition Video, don't expect your sparkling new 802.11n device to handle it, or if it does, don't expect multiple streams.
For a specification that been in the thinking tank now for 4 years, the current speeds are pretty disappointing.
Friday, May 30 2008
Pimped out tech support
I think the recent Dilbert comic is something many computer geeks often face.
Whilst I personally haven't experienced the 'date and dump support' that Dilbert refers to hear, I do see close resemblances of it enough to annoy me.
First off let me explain the personal tech support I don't mind.
I don't mind helping friends and family out. Indeed I enjoy it.
This brings me a sense of accomplishment and I love watching the light-bulbs go on when I explain a technical concept or show them how to resolve the same issue in future.
For me, family tech support is not a burden at all and something I don't mind.
Those close enough to me to receive support, don't normally just have their issue 'fixed', but an explanation of what occurred, how to resolve it in future and how to mitigate it from ever happening again.
I only recently moved my Aunt from Windows (which she's quite proficient on) across to Linux. She's now running a dual boot Windows XP and Ubuntu 8.04 system.
She has been going great guns!
She's got all her peripherals working correctly (monitor/video, card reader, printer and scanner). The only bug bear we currently have is her Palm Zire 21. Though it appears a little more tweaking we will have Palm USB Syncing sorted out.
She's already finding replacement applications under Linux to do away with those she's used under Windows. And we're in the process of moving her data over.
In the long term, we'll probably remove most of the applications off Windows XP and then shrink the partition size down so she can have a larger Linux partition. There will be a few applications that are Windows only and for that she'll more than likely keep a Windows XP partition for those legacy applications (that or we migrate them into a Virtualized Windows machine using something like KVM or VMWare). Some of her 3-D FPS games however are Windows only (and not even available under Wine) -- so Windows on a real partition does have some merit here.
In that sense my Aunt has taken the lead, she's done a lot of ground work and is experimenting and learning at the same time. I love to encourage that and assist her when needed. It's fantastic watching the journey of self-discovery in relation to Linux.
It's these types of jobs (Windows or Linux) I love to see...
Those who can be bothered to take ownership of their own problem and want guidance on how to resolve it, I'm more than happy to assist!
Now, onto the types of personal support I don't like.
How many of you attend a social gathering of someone you know and whilst mingling you're introduced to someone you have never met before?
You're either introduced by your common acquaintance as the 'computer insert phrase here like guru/genius/geek/nerd'. The conversation then quickly swings to one of the following themes:
I have learnt over the years how to brush these off. Not because I can't help. Not because I'm an angry person but mainly if I don't I would find that every waking hour I would be doing personal technical support.
Anyone who works in tech support in any capacity knows that their most precise item is time (Something sadly we appear to have less and less of these days).
These naive people (it's not really there fault, granted ... but some thinking prior to speaking would help!) don't realize just how offending it can be.
Seriously, I didn't study for years and hone my skills over thousands of countless hours so I can be your walking technical wizard that you can wave over "your" issue at your whim!
Those that expect me to sit down and fix their computer for hours at a time... they are the ones I want to drop, they end up becoming multiple offenders, and never actually learn.
So is this a common occurrence for others as well?
Have you learnt how to shake of those needy tech support whores that never want anything more than you to solve their problem and aren't interested in fixing it themselves?
Seriously, what is it with computer tech support? I have friends that are plumbers, mechanics, electricians, chiropractors, lawyers and a range of other professions. I don't get them to fix my taps, car, lights, back, etc all on their personal time and for free. Why is tech support expected to be?
Seriously, I don't want to do it outside hours for a fee anyway. I'm busy enough with work, homelife and attempting to build a house anyway.
Whilst I personally haven't experienced the 'date and dump support' that Dilbert refers to hear, I do see close resemblances of it enough to annoy me.
First off let me explain the personal tech support I don't mind.
I don't mind helping friends and family out. Indeed I enjoy it.
This brings me a sense of accomplishment and I love watching the light-bulbs go on when I explain a technical concept or show them how to resolve the same issue in future.For me, family tech support is not a burden at all and something I don't mind.
Those close enough to me to receive support, don't normally just have their issue 'fixed', but an explanation of what occurred, how to resolve it in future and how to mitigate it from ever happening again.
I only recently moved my Aunt from Windows (which she's quite proficient on) across to Linux. She's now running a dual boot Windows XP and Ubuntu 8.04 system.
She has been going great guns!
She's got all her peripherals working correctly (monitor/video, card reader, printer and scanner). The only bug bear we currently have is her Palm Zire 21. Though it appears a little more tweaking we will have Palm USB Syncing sorted out. She's already finding replacement applications under Linux to do away with those she's used under Windows. And we're in the process of moving her data over.
In the long term, we'll probably remove most of the applications off Windows XP and then shrink the partition size down so she can have a larger Linux partition. There will be a few applications that are Windows only and for that she'll more than likely keep a Windows XP partition for those legacy applications (that or we migrate them into a Virtualized Windows machine using something like KVM or VMWare). Some of her 3-D FPS games however are Windows only (and not even available under Wine) -- so Windows on a real partition does have some merit here.
In that sense my Aunt has taken the lead, she's done a lot of ground work and is experimenting and learning at the same time. I love to encourage that and assist her when needed. It's fantastic watching the journey of self-discovery in relation to Linux.
It's these types of jobs (Windows or Linux) I love to see...
Those who can be bothered to take ownership of their own problem and want guidance on how to resolve it, I'm more than happy to assist!
Now, onto the types of personal support I don't like.
How many of you attend a social gathering of someone you know and whilst mingling you're introduced to someone you have never met before?
You're either introduced by your common acquaintance as the 'computer insert phrase here like guru/genius/geek/nerd'. The conversation then quickly swings to one of the following themes:
- I am thinking of buying a new computer...
- Can you get me a new computer cheap?
- Do you have a copy of insert either a Microsoft product or other proprietary software?
- Something is wrong... (goes on to explain how they have
porn advertsadverts popping up on their screen). - I clicked on this link/Email. (goes on to explain that ever since his computer does weird things -- basically infected by a virus/trojan/is now part of a zombie network).
- Where can I download (goes on to say they want pirated software/music/videos).
I have learnt over the years how to brush these off. Not because I can't help. Not because I'm an angry person but mainly if I don't I would find that every waking hour I would be doing personal technical support.
Anyone who works in tech support in any capacity knows that their most precise item is time (Something sadly we appear to have less and less of these days).
These naive people (it's not really there fault, granted ... but some thinking prior to speaking would help!) don't realize just how offending it can be.
Seriously, I didn't study for years and hone my skills over thousands of countless hours so I can be your walking technical wizard that you can wave over "your" issue at your whim!
Those that expect me to sit down and fix their computer for hours at a time... they are the ones I want to drop, they end up becoming multiple offenders, and never actually learn.
So is this a common occurrence for others as well?
Have you learnt how to shake of those needy tech support whores that never want anything more than you to solve their problem and aren't interested in fixing it themselves?
Seriously, what is it with computer tech support? I have friends that are plumbers, mechanics, electricians, chiropractors, lawyers and a range of other professions. I don't get them to fix my taps, car, lights, back, etc all on their personal time and for free. Why is tech support expected to be?
Seriously, I don't want to do it outside hours for a fee anyway. I'm busy enough with work, homelife and attempting to build a house anyway.
Thursday, May 29 2008
Opening up your home NAS
The Maxtor Shared Storage Plus
It's basically a 500GB disk inside an enclosure that you network (10/100Mbps), and contains 2 additional USB ports so you either plug additional USB storage or a USB printer into (to make it a networked printer).
In our instance we use it mainly for backing up. For this purpose it serves well.
We ran into a problem today when the device filled.
That was unusual, as we traditionally have loads of space left on it (we only backup our content/configurations), not the OS or applications... and we purge old backups.
A closer inspection showed that the backup software we were running on the Windows machine was actually not removing old archive files. That explained the lack of disk space.
It seemed under certain conditions that the Windows machine was unable to delete the files it created.
This now appears more an issue with Windows then the actual backup software. (I could delete the mentioned files using Nautilus fine under Linux, just not through Explorer!) 
MSS Plus Web Administration Interface
It always was frustrating that besides the web-interface to manage the device, that SMB appeared to be the only option available for file management.
Many people have used SLUGs (aka NSLU2 - LinkSys's NAS device). This allowed people to use modified firmware to create a nice embedded Linux device, allowing them to install additional software and expand on the base functionality.
How nice would this be with my MSS+
I thought I would take a peep at the support website, as I realized that this device too is likely to use OSS software such as Samba to create it. Low and behold, the source code was available.
This got my creative juices running! Could I use this to create a modded version myself and add items like NFS, FTP and SSH to the device? Surely someone else has already thought the same thing.
Apparently they have! OpenMSS is just that. Not only does it put down a telnet server by default (so you can login, they have got BusyBox working on it as well.
From my reading it appears NFS is there, just was never enabled on the original firmware image. It also allows you to install additional software, as well as a bunch of software from the ports made available through the work by the guys over as nslu2-linux.org.
It looks like with little work I'll be able to have an FTP, NFS and rsync all as options, as well as SSH to login to the box.
The list of packages available is breath-taking, and I can see a lot of work has gone into the porting.
What's even better, the web-interface and existing data stay intact when migrating over to OpenMSS -- just the ability to get into the heart of the box is opened up.
So I think it's now a case of having a play around and actually getting some 'smarts' into this device.
I'm doing away with the Windows backup software and we'll look at running a central backup from the device itself to pull in backups from other hosts using rsync. (much nicer). I see ccollect is one of the packages available, so this may indeed do the trick... just through on vixie cron at the same time and I've got a nice simple and effective solution.I felt a little cheated initially when I heard of the SLUG (after my MSS+ purchase) now I'm feeling quite happy that I can play in the same league!
It's a job for later in the week/weekend (when time permits), but it appears I may have just solved some of the issues that has been burning me for ages (access to the device and trouble free backups from Windows to it). I'll keep you posted on the outcome.
Don't ya just love OSS -- putting the power back in the users hands!
Wednesday, May 28 2008
UPS monitoring under Linux
I recently made reference to the fact I purchased some UPSes.
For our desktop machines I purchased 2 x Powerware 5110 1500VA units. We also purchased a 1 x Powerware 5125 2200VA (15A socket) to run our 19" racks. (This will also include some networking gear, a 8-port KVM with 15" LCD monitor, and a reasonable server and Disk Arrays).
I make it a habit when sizing a UPS of ensuring I don't load it too high. Whilst I can run many things on each UPS, I would refer a relatively low load, so that if required I can hold the box up long enough to shutdown everything safely. There is nothing worse than hard crashing a server because the UPS load sat at 70-80% load and couldn't hold up for 5-10 minutes whilst machines started shutting down. This is particularly true of a busy database server.
I generally try to run a UPS load of around < 50% and ideally between 10-30% if I can. I would rather have a few minutes up my sleeve then spending time worrying whether I will be able to recover from backup.
The software that comes with the Powerware 5110 runs under Windows. (They do provide 'Linux' software but it's pretty shoddy and a PITA to try and get working).
LanSafe - does work well under Windows.
Pauline runs Windows as her default OS (mainly due to her need for MYOB and ATO's ECI Client Software both only native to Windows. There is also the occasional business website she requires that is IE only - much to our disgust...)
We will probably look at moving her over to a Linux desktop in the future and running Windows in either a dual boot or virtual machine. In fact, we'll probably do that sooner rather than later, for a number of reasons.
I wanted something that easy under my Linux desktop (Ubuntu in this case).
That's where NUT comes in.
NUT supports a wide range of UPS makes, models and connectivity options. Feature-wise it is quite impressive.
Reading through the documentation for NUT it's quite clear that you can extend on the notifications you can generate. From items like sending wall messages, Emails, syslog alerts, to even Email messages. You can even get an OSD display if the UPS state changes. I'll probably make use of the SMS daemon I wrote about previously to send me an SMS.
Apparently Gnome Power Manager is supposed to pickup a UPS (it is just a battery after all) is attached. Seems it doesn't in this instance. (I'm happy to be corrected -- but I'm yet to find anything on the web that shows so much for this UPS).
There has been a bit of discussion in recent times of getting an independent system together that relies on D-BUS/HAL so that other Window Managers can also hook into it. A lot like what we're seeing now in Network Manager (love or hate it!) (See: BetterPowerManager and the Power Management Specification
For the record, you can also use check_ups from Nagios to actively monitor your UPS that is being managed by NUT
Those using an APC UPS should look at apcupsd (a new stable version was just released on the 20th of May 2008). There is also native Windows versions available.
For our desktop machines I purchased 2 x Powerware 5110 1500VA units. We also purchased a 1 x Powerware 5125 2200VA (15A socket) to run our 19" racks. (This will also include some networking gear, a 8-port KVM with 15" LCD monitor, and a reasonable server and Disk Arrays).
I make it a habit when sizing a UPS of ensuring I don't load it too high. Whilst I can run many things on each UPS, I would refer a relatively low load, so that if required I can hold the box up long enough to shutdown everything safely. There is nothing worse than hard crashing a server because the UPS load sat at 70-80% load and couldn't hold up for 5-10 minutes whilst machines started shutting down. This is particularly true of a busy database server.
I generally try to run a UPS load of around < 50% and ideally between 10-30% if I can. I would rather have a few minutes up my sleeve then spending time worrying whether I will be able to recover from backup.
The software that comes with the Powerware 5110 runs under Windows. (They do provide 'Linux' software but it's pretty shoddy and a PITA to try and get working).
LanSafe - does work well under Windows.
Pauline runs Windows as her default OS (mainly due to her need for MYOB and ATO's ECI Client Software both only native to Windows. There is also the occasional business website she requires that is IE only - much to our disgust...)
We will probably look at moving her over to a Linux desktop in the future and running Windows in either a dual boot or virtual machine. In fact, we'll probably do that sooner rather than later, for a number of reasons.
- End of Life for Windows XP Professional has been announced, for early next year. (if you don't get 'Extended Support' which most consumers won't be offered - it's mainly for business.).
- We've purchased 2 x 1TB SATA2 disks for her machine
- A reinstall of Windows may resolve the long delay at startup she faces - upto 5 minutes before the machine becomes 'usable'. Yes, we've cleaned the registery, removed any unwanted startup programs, defragged the disk, and even cleaned out old pre-fetch data. It's still a mystery.
I wanted something that easy under my Linux desktop (Ubuntu in this case).
That's where NUT comes in.
NUT supports a wide range of UPS makes, models and connectivity options. Feature-wise it is quite impressive.
Reading through the documentation for NUT it's quite clear that you can extend on the notifications you can generate. From items like sending wall messages, Emails, syslog alerts, to even Email messages. You can even get an OSD display if the UPS state changes. I'll probably make use of the SMS daemon I wrote about previously to send me an SMS.
Apparently Gnome Power Manager is supposed to pickup a UPS (it is just a battery after all) is attached. Seems it doesn't in this instance.
(I'm happy to be corrected -- but I'm yet to find anything on the web that shows so much for this UPS).There has been a bit of discussion in recent times of getting an independent system together that relies on D-BUS/HAL so that other Window Managers can also hook into it. A lot like what we're seeing now in Network Manager (love or hate it!) (See: BetterPowerManager and the Power Management Specification
For the record, you can also use check_ups from Nagios to actively monitor your UPS that is being managed by NUT
Those using an APC UPS should look at apcupsd (a new stable version was just released on the 20th of May 2008). There is also native Windows versions available.
Saturday, May 24 2008
Nagios 2-way alerting via SMS - Part 3
This is a 3 part posting that covers how you can setup 2-way Nagios alerting via SMS.
The series is broken down as such:
Review
As we saw in Part 2 we covered setting up Nagios to send out alerts.
Whilst this is great, it's not of great value if we can't do anything with these SMS messages. In addition, if no-one is sitting in front of the actual Nagios web console to acknowledge the issue, then Nagios will continue sending the SMS messages and will quickly fill up your phone's message memory. Not ideal!
The message is quite straight forward as well to read. A service problem message contains:
Here is a Host problem message for comparison:Replying to the Nagios Problem SMS
When a problem from Nagios is sent to you via SMS it's quite easy to respond.
All you need to do is reply to the message (and include the text - which most mobile phones on the market provide a feature to do).
Whilst not required, you can append a simple message to your reply. This will be used in the acknowledgment response and add a comment to the service.
Comments don't need to be long, but they do help your other team members or interested parties know what is happening with the issue.
Be careful what you write!
The response you send will also be used in a follow-up SMS to everyone notifying them that someone is looking at the issue. You don't want to send something that might not be appreciated others that recipients
Acknowledging SMS messages
Acknowledging messages from Nagios is quite simple now we have our SMS Daemon setup (see Part 2 for details)
As a result, any incoming SMS messages get stored into our MySQL database.
We just need a process now to read them from the database, interpret them and then update Nagios appropriately.
The series is broken down as such:
- Part 1: Background and Requirements
- Part 2: Sending SMS messages from Nagios
- Part 3: Acknowledging SMS messages (this article)
Review
The SMS message Nagios generates when there is a problem.
Whilst this is great, it's not of great value if we can't do anything with these SMS messages. In addition, if no-one is sitting in front of the actual Nagios web console to acknowledge the issue, then Nagios will continue sending the SMS messages and will quickly fill up your phone's message memory. Not ideal!
The message is quite straight forward as well to read. A service problem message contains:
- The type of incident: PROBLEM
- The Host affected
- The Service affected
- The Severity of the incident
- Additional Information about the incident.
- The Time of the incident
- A field to Respond/acknowledge the incident
Here is a Host problem message for comparison:
- PROBLEM
Host 'MyServer' is DOWN
I: CRITICAL - Host Unreachable (10.0.0.74)
T: 2008-05-22 17:52:33
R:
Sending a response back to Nagios via SMS.
All you need to do is reply to the message (and include the text - which most mobile phones on the market provide a feature to do).
Whilst not required, you can append a simple message to your reply. This will be used in the acknowledgment response and add a comment to the service.
Comments don't need to be long, but they do help your other team members or interested parties know what is happening with the issue.
Be careful what you write!
The response you send will also be used in a follow-up SMS to everyone notifying them that someone is looking at the issue. You don't want to send something that might not be appreciated others that recipients
Acknowledging SMS messages
Acknowledging messages from Nagios is quite simple now we have our SMS Daemon setup (see Part 2 for details)
As a result, any incoming SMS messages get stored into our MySQL database.
We just need a process now to read them from the database, interpret them and then update Nagios appropriately.
Continue reading "Nagios 2-way alerting via SMS - Part 3"
Monday, May 19 2008
Nagios 2-way alerting via SMS - Part 1
This is a 3 part posting that covers how you can setup 2-way Nagios alerting via SMS.
The series is broken down as such:
For those that wish to setup simple, inexpensive monitoring you will find that it is simpler than first thought. Feel free to grab the code-snippets provided over the series and make use of it in your own environment.
The Nagios SMS alert system has been running here now in production for approximately 6 months and works quite well. The Nagios system manages a range of services/hosts and checks approximately 1,500 items (by no means large); it has however cut down the amount of time I require looking at Nagios alert screens.
Background and Requirements
Background
I like to dabble in web development and have now for around 10 years. As a result I undertake hosting in commercial data centers in order to ensure maximum uptime and good responsiveness. To offset the cost, I now provide hosting/email and web-development services to a number of clients.
As a result, it means one cannot easily look at the diagnostic LEDs, or even the console easily to determine when a problem has occurred. (Whilst I can make use of an IP KVM; it is normally a PITA and best avoided!)
Ideally I was after a monitoring system that alerted me prior to a problem so that I can deal with it before it became a bigger issue.
Nagios was chosen as it provided all the features we required, had support for a large number of items we wished to monitor, and was simple to extend to check custom services based on being written in Perl. Nagios comes with a swag of documentation making it easy to write simple checks or extend on as was seen fit. As I've coded a fair amount in Perl over the years for various System Administration tasks, Nagios was seen as a good fit. Being an Open-Source project ensured that it was an added bonus of both being free-to-use, but also I had access to the source code to understand better how the system worked.
I have used Nagios for years now, and historically have relied on web/email alerts. However, being human means I can't always be in front of my computer 24x7. This worked the majority of the time, though as luck would have it we ended up with a system failure that occurred early one mid-week morning. As a result it was decided we needed to put a system in place that alerted when something occurred when I wasn't in front of the computer.
We already had a working Nagios monitoring environment, so we wanted to make use of this system going forward.
Requirements
I wrote down our requirements for a paging system. I wanted to ensure whatever solution was put in place that it could grow with us, but also that we weren't locked into a solution for years or even worse, that we embarked upon a solution that would ultimately restrict any future requirements we might have.
There were several ways we could be alerted:
We ruled out a telephone, as a recorded message wouldn't provide us any real details of what the issue was, unless we actually started recording exactly what the issue was. It was beginning to look too complicated for a simple requirement. I really thought a Voice-IVR was an overkill for what we required. (Whilst it may of indeed been fun to hack/configure!)
A pager was then looked into. Whilst pagers work well in ensuring a message is delivered we saw this as a drawback, in the sense it meant carrying around another device on us. (We already carried a mobile phone and the prospect of carrying a pager didn't appeal). Also pagers traditionally send one-way messages; and we wanted a system where we could acknowledge an alert.
We settled on a alert delivery system to be used via SMS. Whilst SMS doesn't have the guaranteed delivery system of that of a pager, it did open up the possibility of being able to respond to an alert. It had the added bonus that we already carried our mobiles close by 24x7 so there was no need to carry an additional device. Using a SMS to deliver a text based message also ensured we could then place useful information in the message to assist in the problem diagnosis.
We had now determined our delivery system (SMS), it was time to find technical solutions that would fit in with the existing Nagios monitoring platform.
Nagios by default has the ability to alert via various means. Pagers, SMS and Emails are handled quite easily within the standard configuration that ships with the software.
It would make the integration of SMS quite easily. However, it was only by default a 1-way system. There was no provision to handle a 2-way message. ( Alert Message then acknowledgment message)
A 2-way SMS alert system was preferred as it could be setup to stop alerting us continually via SMS once the alert had been acknowledged. It also had the added benefit that whilst the message was sent to other parties, it could also ensure that they were aware the problem was being investigated and avoid duplication of work.
We also wanted to run the SMS alert system as close as possible to the Nagios monitoring host. This would ensure that if we had a physical network or IP link down, we could still get messages out. This cut out using a 3rd party SMS service.
Coming Up In the next part of the series...
In the next part, I'll describe the components that make up our 2-way SMS solution using OSS software and some of the scripts we hacked together to 'glue' the solution together.
It's now been running without a hitch now for about 6 months.
We also use it as a Web2SMS gateway locally, as well as being open enough that I can utilize it via the CLI to send out alerts.
Looking back the solution was quite simple, and met all our requirements.
The series is broken down as such:
- Part 1: Background and Requirements (this article)
- Part 2: Sending SMS messages from Nagios
- Part 3: Acknowledging SMS messages
For those that wish to setup simple, inexpensive monitoring you will find that it is simpler than first thought. Feel free to grab the code-snippets provided over the series and make use of it in your own environment.
The Nagios SMS alert system has been running here now in production for approximately 6 months and works quite well. The Nagios system manages a range of services/hosts and checks approximately 1,500 items (by no means large); it has however cut down the amount of time I require looking at Nagios alert screens.
Background and Requirements
Background
I like to dabble in web development and have now for around 10 years. As a result I undertake hosting in commercial data centers in order to ensure maximum uptime and good responsiveness. To offset the cost, I now provide hosting/email and web-development services to a number of clients.
As a result, it means one cannot easily look at the diagnostic LEDs, or even the console easily to determine when a problem has occurred. (Whilst I can make use of an IP KVM; it is normally a PITA and best avoided!)
Ideally I was after a monitoring system that alerted me prior to a problem so that I can deal with it before it became a bigger issue.
Nagios was chosen as it provided all the features we required, had support for a large number of items we wished to monitor, and was simple to extend to check custom services based on being written in Perl. Nagios comes with a swag of documentation making it easy to write simple checks or extend on as was seen fit. As I've coded a fair amount in Perl over the years for various System Administration tasks, Nagios was seen as a good fit. Being an Open-Source project ensured that it was an added bonus of both being free-to-use, but also I had access to the source code to understand better how the system worked.
I have used Nagios for years now, and historically have relied on web/email alerts. However, being human means I can't always be in front of my computer 24x7. This worked the majority of the time, though as luck would have it we ended up with a system failure that occurred early one mid-week morning.
As a result it was decided we needed to put a system in place that alerted when something occurred when I wasn't in front of the computer.We already had a working Nagios monitoring environment, so we wanted to make use of this system going forward.
Requirements
I wrote down our requirements for a paging system. I wanted to ensure whatever solution was put in place that it could grow with us, but also that we weren't locked into a solution for years or even worse, that we embarked upon a solution that would ultimately restrict any future requirements we might have.
There were several ways we could be alerted:
- Telephone: Have the system 'call us'. Possibly play a standard recorded message.
- Pager: Make use of an alpha-numeric pager.
- SMS: Send a text message.
We ruled out a telephone, as a recorded message wouldn't provide us any real details of what the issue was, unless we actually started recording exactly what the issue was. It was beginning to look too complicated for a simple requirement. I really thought a Voice-IVR was an overkill for what we required. (Whilst it may of indeed been fun to hack/configure!)
A pager was then looked into. Whilst pagers work well in ensuring a message is delivered we saw this as a drawback, in the sense it meant carrying around another device on us. (We already carried a mobile phone and the prospect of carrying a pager didn't appeal). Also pagers traditionally send one-way messages; and we wanted a system where we could acknowledge an alert.
We settled on a alert delivery system to be used via SMS. Whilst SMS doesn't have the guaranteed delivery system of that of a pager, it did open up the possibility of being able to respond to an alert. It had the added bonus that we already carried our mobiles close by 24x7 so there was no need to carry an additional device. Using a SMS to deliver a text based message also ensured we could then place useful information in the message to assist in the problem diagnosis.
We had now determined our delivery system (SMS), it was time to find technical solutions that would fit in with the existing Nagios monitoring platform.
Nagios by default has the ability to alert via various means. Pagers, SMS and Emails are handled quite easily within the standard configuration that ships with the software.
It would make the integration of SMS quite easily. However, it was only by default a 1-way system. There was no provision to handle a 2-way message. ( Alert Message then acknowledgment message)
A 2-way SMS alert system was preferred as it could be setup to stop alerting us continually via SMS once the alert had been acknowledged. It also had the added benefit that whilst the message was sent to other parties, it could also ensure that they were aware the problem was being investigated and avoid duplication of work.
We also wanted to run the SMS alert system as close as possible to the Nagios monitoring host. This would ensure that if we had a physical network or IP link down, we could still get messages out. This cut out using a 3rd party SMS service.
Coming Up In the next part of the series...
In the next part, I'll describe the components that make up our 2-way SMS solution using OSS software and some of the scripts we hacked together to 'glue' the solution together.
It's now been running without a hitch now for about 6 months.
We also use it as a Web2SMS gateway locally, as well as being open enough that I can utilize it via the CLI to send out alerts.
Looking back the solution was quite simple, and met all our requirements.
Tuesday, May 13 2008
Asterisk, Snom-300 VOIP phone and Power Over Ethernet.
Well it's coming up to the end of financial year, and like many businesses we needed to make a few purchases. (That or pay more corporate tax -- hmmm let me think.. more toys or more tax? )
Generally we don't make many purchases throughout the year and then buy up large near the end of the financial year. (well unless something fails!)
As such we decided to get a decent VOIP phone. We currently use a LinkSys SPA3102 with our cordless phone, but wanted to get a phone with a decent headset so we could talk hands free easily.
We spoke to a few people, did the research and settled on a Snom VOIP phone. In particular, we elected the Snom-300 as the phone of choice for us. Whilst it claims it's the 'base phone', unless you're mega-boss or a telemarketing guru I doubt the snom-320 or snom-360 phones are really required. (They basically have a lot of additional buttons and few features added to the base functionality).
You can configure the phone via the LCD menu system, or use the built in web based configuration. The web-based configuration is very well laid out and easy to navigate and locate what you need.
Upgrading the phones firmware is extremely easy and quite painless. You can watch the progress of the phone being flashed, and it's quite novel to see items like chroot, mount appear on your phones LCD.
Chroot, mount you say?! Yup, at the heart of every Snom is a Linux kernel. Whilst this wasn't the sole reason for buying the device, it's handy to know that with a bit of time I could in theory hack the phone.
I unfortunately get stuck is long boring teleconferences far too often, so I wanted to ensure I also had a phone that was able to plugin in a headset. Not all IP VOIP phones we looked at seemed to have that feature.
The Snom phones do, however they use an RJ-11 headset connection instead of a 2.5mm or 3.5mm jack that people are most familar with. (Many cordless phones also use the 2.5/3.5mm jacks).
As such, we decided to purchase them. They don't come cheap but are worth it. It's a much better solution than getting 'neck cramp' attempting to hold the phone under your chin, or even speaker phone (which seems to pickup more background noise), which can annoy anyone else within earshot.
With the headset, I'm able to easily keep working on my computer; punching away on the keyboard, and those on the other end are none the wiser! (Well besides being too distracted to really keep up with the conversation; dang! I think I just let my secret out....and to think -- people just thought I was vague on the phone!)
Our current setup has me registering both the ATA and the Snoms devices registering directly to our VOIP provider. This works fine, and allows multiple out going calls at the same time, but means only our ATA rings for incoming calls (we have two DIDs).
It makes sense, as the ATA picks up the incoming request and responds... well before the Snoms do. How to resolve?
Easily -- Asterisk to the rescue!
I can setup Asterisk as our local PBX (or PABX for those in Australia!), and have all devices register to it. Then the Asterisk server registers with our Voice Provider.
A bit of Asterisk config and I should be able to get all the phones to ring. In addition, it will allow me to use T.38, add MOH, and voice mail. I also like the ability to have local extensions so we can forward calls between various devices. Currently both Pauline and I share an office, but in our new house we'll be up other ends of the house. So call transfers make sense. I think it would be great to also create an IVR application that puts telemarketers into a loop of endless questions. (randomly generated of course -- so they aren't aware!) Though I think Paul Dwerryhouse's idea is probably the solution.
I'm a newbie to Asterisk (though I've been aware of it for a while -- I just haven't had a need for it)... so I imagine it might take me some time to configure it all up as we desire.
Once done, the only thing Telstra will be getting out of us will be the cheapest line rental we can pay. (They overcharge for that as well!) Though, there is not much getting around it whilst stuck on an ADSL1 connection.
Another purchase we made for the upcoming house was a nice 48-port managed Gigabit switch that contains 12 POE (Power over Ethernet) ports. These will be used to power our phones in the future, saving the need for the current power-pack.
The switch we went for is a D-Link DGS-3100-48P. Like most large switches it's full of fans and sounds like a DC-7 taking off. As a result, it's safely packed back in it's box and will be used after the house move!
We also purchased to UPSes (the old ones had dead batteries) -- strangely it's cheaper buying new UPSes than batteries.
So we ended up with 1 x 1500VA UPS and a 1 x 2200VA UPS.
It appears we'll probably need one more 1500VA.
I went with Powerware UPSes as their is reasonably good local support (and hopefully battery replacements!), and nut seems to work well.
All in all it's been a good month for hardware toys to play with.
Shame a fair bit of this new gear is a few months off until we get into the new house!
Now if only those Intel 8-core Xeons were out.... (my desired replacement server that will consolidate everything down!) If you wish to view a demo of what's coming.. take a look at the Intel demonstration.
)Generally we don't make many purchases throughout the year and then buy up large near the end of the financial year. (well unless something fails!)
As such we decided to get a decent VOIP phone. We currently use a LinkSys SPA3102 with our cordless phone, but wanted to get a phone with a decent headset so we could talk hands free easily.
Snom-300. An excellent VOIP phone, with fantastic voice quality and a solidly built professional phone.
You can configure the phone via the LCD menu system, or use the built in web based configuration. The web-based configuration is very well laid out and easy to navigate and locate what you need.
Upgrading the phones firmware is extremely easy and quite painless. You can watch the progress of the phone being flashed, and it's quite novel to see items like chroot, mount appear on your phones LCD.
Chroot, mount you say?! Yup, at the heart of every Snom is a Linux kernel.
Whilst this wasn't the sole reason for buying the device, it's handy to know that with a bit of time I could in theory hack the phone.The Snom-300 HS-MM3 headset is both comfortable and functional. Sound is clear and crisp through it.
The Snom phones do, however they use an RJ-11 headset connection instead of a 2.5mm or 3.5mm jack that people are most familar with. (Many cordless phones also use the 2.5/3.5mm jacks).
As such, we decided to purchase them. They don't come cheap but are worth it. It's a much better solution than getting 'neck cramp' attempting to hold the phone under your chin, or even speaker phone (which seems to pickup more background noise), which can annoy anyone else within earshot.
With the headset, I'm able to easily keep working on my computer; punching away on the keyboard, and those on the other end are none the wiser! (Well besides being too distracted to really keep up with the conversation; dang! I think I just let my secret out....and to think -- people just thought I was vague on the phone!)
Our current setup has me registering both the ATA and the Snoms devices registering directly to our VOIP provider. This works fine, and allows multiple out going calls at the same time, but means only our ATA rings for incoming calls (we have two DIDs).
It makes sense, as the ATA picks up the incoming request and responds... well before the Snoms do. How to resolve?
Easily -- Asterisk to the rescue!
I can setup Asterisk as our local PBX (or PABX for those in Australia!), and have all devices register to it. Then the Asterisk server registers with our Voice Provider.
A bit of Asterisk config and I should be able to get all the phones to ring. In addition, it will allow me to use T.38, add MOH, and voice mail. I also like the ability to have local extensions so we can forward calls between various devices. Currently both Pauline and I share an office, but in our new house we'll be up other ends of the house. So call transfers make sense. I think it would be great to also create an IVR application that puts telemarketers into a loop of endless questions. (randomly generated of course -- so they aren't aware!) Though I think Paul Dwerryhouse's idea is probably the solution.
I'm a newbie to Asterisk (though I've been aware of it for a while -- I just haven't had a need for it)... so I imagine it might take me some time to configure it all up as we desire.
Once done, the only thing Telstra will be getting out of us will be the cheapest line rental we can pay. (They overcharge for that as well!)
Though, there is not much getting around it whilst stuck on an ADSL1 connection.Another purchase we made for the upcoming house was a nice 48-port managed Gigabit switch that contains 12 POE (Power over Ethernet) ports. These will be used to power our phones in the future, saving the need for the current power-pack.
The switch we went for is a D-Link DGS-3100-48P. Like most large switches it's full of fans and sounds like a DC-7 taking off. As a result, it's safely packed back in it's box and will be used after the house move!
We also purchased to UPSes (the old ones had dead batteries) -- strangely it's cheaper buying new UPSes than batteries.
So we ended up with 1 x 1500VA UPS and a 1 x 2200VA UPS.
It appears we'll probably need one more 1500VA.
I went with Powerware UPSes as their is reasonably good local support (and hopefully battery replacements!), and nut seems to work well.
All in all it's been a good month for hardware toys to play with.
Shame a fair bit of this new gear is a few months off until we get into the new house!
Now if only those Intel 8-core Xeons were out.... (my desired replacement server that will consolidate everything down!) If you wish to view a demo of what's coming.. take a look at the Intel demonstration.