I recently finished my desk project by adding the perfboard backing between the two computer cabinets. This had always been the plan after I finished the bookshelves, but it took me awhile to get around to doing it. Adding the perfboard allowed me to get the tangle of cables off the ground, sorted out, and tied down so they wouldn’t work themselves loose. When I first installed the perfboard, however, I had two problems: the network cables were tangled up in a really bad way, as were the power cables to all the systems. In order to not knock out the house’s internet connection for an hour while everyone was home and using it, I just pushed those cables to the side and decided to deal with them later.

Yesterday was later. While everyone else was out, I shut everything down, took it all apart, and rerouted all the cables in sane ways. It’s still not pretty, but it’s far better than it was. I also took the opportunity to make sure my Mac and the fileserver with the iSCSI volumes on it were on the same switch – and not the Airport Extreme. The problem being that every time the network goes away, the SNS iSCSI driver kernel panics the Mac, and every time you make a networking change to the Airport, it reboots, shutting off the network connections. Not exactly a recipe for a healthy computer. I’m using iSCSI because I don’t have a fast enough physical drive for my Aperture library to maintain decent performance, and because you can’t launch an Aperture library from a network volume. iSCSI appears to be local from the Mac’s perspective, and I get to use the benefit of the ZFS caching structure when working on photos. It’s so much faster, I’ll live with the annoyances of iSCSI, at least until 256 GB SSD’s are less than $100.

In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``

There is a simple configuration file in ```In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``

There is a simple configuration file in``. You will need to set up the modem device, the providers and the users in this file. Once it's setup, test it by starting up qpage in it's deamon mode (and turn debugging on):./qpage -q 10 -dand then issuing pages from a separate session and using theqpagebinary. You can even use theqpage` binary from another system if you don’t have TCP port 444 firewalled.

Finally, you will also need an init script so you can set the SNPP qpage daemon to run at boot time. Here’s mine:

````In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``

There is a simple configuration file in ```In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``In the last post on this topic, we walked through setting up a modem and a phone line for use in a Linux server. I’m using RHEL/CentOS as my Linux platform, so there may need to be some tweaks for getting this working in other distributions. Today, we’re going to talk about setting up qpage. qpage is no longer under active development, but the most recent version (3.3), works perfectly with modern kernels and modem hardware.

Head over to the download page and grab a copy of the software. You will need to make sure you have developers tools installed on your system to build qpage. On RHEL the following command is sufficient:

sudo yum groupinstall "Developer tools"

``

There is a simple configuration file in``. You will need to set up the modem device, the providers and the users in this file. Once it's setup, test it by starting up qpage in it's deamon mode (and turn debugging on):./qpage -q 10 -dand then issuing pages from a separate session and using theqpagebinary. You can even use theqpage` binary from another system if you don’t have TCP port 444 firewalled.

Finally, you will also need an init script so you can set the SNPP qpage daemon to run at boot time. Here’s mine:

````

In the third and final article on this, I’ll talk about setting up nagios alerts to send pages.

For everyone else trying to get good full moon snaps, there’s a “Super Moon” tonight. The moon is closer to the earth than usual (220,00 miles instead of 254,000 miles), which happens to coincide with the full moon. This means the moon will be slightly bigger and slightly brighter than usual, and means I’m all the more keen to get good full moon shots.

If you are looking to see what tonight’s cloud cover is in your area, there’s also a handy utility hosted on cleardarksky that can tell you 36 hours out what the sky conditions and cloud cover should be like.

Best of luck!

Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W `ATI9``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W `ATI9`````` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W `ATI9``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W``` Sending out-of-band alerts is one of the core concepts in monitoring. You can think it through this way: never try to alert about a trouble with an email server by sending email and never try to use internet services to report on network outages. Considering most of what I do at work relies heavily on the network, it makes sense to configure the monitoring system to use things other than the email gateway or an XMPP federated chat client to alert administrators about problems.

The most common methods to deliver these alerts is the Short Message Service, also known as SMS. With the rapid proliferation of smart phones amongst server administrators and, more importantly, unlimited SMS texting plans, this is the easiest way to alert admins of problems without relying on infrastructure that you control. Setting up gnokii-smsd to relay messages via a USB attached GSM cell phone is easy enough.

There are a large number of administrators in the US, however, that live in places that don’t get adequate cell coverage, or who’s work won’t provide SMS plans for their devices. If they are in an on-call rotation, it’s likely that they have an analog pager – one that you actually pick up a phone and dial a number to deliver messages to. The signal strength requirements for these devices is an order of magnitude less than that of a standard mobile phone, and are quite reliable. Thankfully, delivering pages to analog pagers costs less than $150 plus the recurring costs of a phone line.

This is the setup.

Get a PCIe modem and install it in your server. We’re using a MultiTech Systems “MT9234ZPX-PCIE-NVC2” – which is a standard low profile PCIe card. Handily, the driver is already in the 2.6 series of kernels, so unless you have a serial card installed, you’re good to go. (And, yes, you can use an older modem that plugs into the serial port, but then you’ve got even more wires and power supplies to deal with.)

Next, make an alias in /dev to the proper serial port. Just ln -s /dev/modem /dev/ttyS3, where ttyS3 is your serial device. Fire up minicom, initialize the country-specific settings (AT%T19,0,37), disable dial tone detection (AT&D0&W) and write the firmware to the card (AT&F&W `ATI9``````

Test that you can actually use the phone line by using ATDT 1234567890, entering in your phone number where appropriate. If you need to get an outside line, commonly by dialing a 9 and waiting for a few seconds, pre-pend 9, to the number – the comma tells the modem to wait for a second before dialing the rest of the numbers.

Congratulations! You now have a working modem. In the next post, I’ll talk about setting up QPage, the software you’ll use to queue and send pages.

MAKE Projects: So many good ideas, so little time.

Kids today have missed the whole experience of putting the headphones on, turning it up to 10, holding the jacket, closing their eyes and getting lost in an album; and the beauty of taking your allowance money and making a decision based on the jacket, not knowing what the record sounded like, and looking at a couple of still pictures and imagining it.

–Jon Bon Jovi, in an interview with The Sunday Times

I’m sorry, Jon. You are an idiot. I like knowing when an album is a bunch of crappy tracks crammed in around the one or two hits that will get overplayed on the radio. I like to know this before I spend my hard earned money on the music. If you want people to buy albums, make music good enough that people want all the tracks. Then, they will buy the albums.

Twitter is making headlines these days. With Sheen gaining followers on twitter as fast as he’s losing television advertising dollars and the so called dickbar they recently added to promote paid tweets, people are talking about Twitter wherever you go. (And, by writing this post, I guess that includes the Guru College) What gets me is that Twitter really doesn’t have a long term strategy that I can see. They provide a service that is free to sign up for, free to use, and a lot of people use very heavily. I can’t imagine their server bills are low. There’s no easy way to monetize the service without pissing a lot of people off, and it’s not like it’s a hard service to replicate if you can handle the load.

So, to combat this… Twitter tells us they are going to limit what 3rd party clients can and can’t do. Which makes a lot of sense – make your developers angry or distrustful so they won’t develop for your platform anymore, and you can then… sell… more… paid tweets? Why does this sound like “and Step #3: Profit” to me?