The first problem is that AWS only distribute the tools as an RPM (really guys? I mean FFS). Convert and install with alien.

# apt-get install alien
# alien -k ec2-ami-tools.noarch.rpm
# dpkg -i ec2-ami-tools_1.3-15283_all.deb

Make sure you also install libopenssl-ruby.

Set your Ruby path as the RPM places them where RedHat expects to find them:

# export RUBYLIB="/usr/lib/site_ruby"

Now when you run the utility, you’ll probably get:

$ ec2-bundle-image -r ... -i ... -k ... -c ... -u ...
sh: Syntax error: Bad substitution

Aparently Ubuntu switched from invoking bash to dash for sh somewhere along the line. Just relink it (temporarily or permanently as suits):

# rm /bin/sh
# ln -s /bin/bash /bin/sh

And you should be good to go.

One other issue I encountered was that the permissions of the directories were for root only (i.e. /usr/local/aes, /usr/lib/site_ruby/ and /etc/aes). A very sloppy chmod a+rX on each of these will resolve that. Although I suspect it’s more to do with the fact that I used rpm2cpio and cpio rather than alien the first time around.

To this end, I have written a Nagios plugin which queries Asterisk’s manager interface and executes the pri show spans CLI command (this is Asterisk 1.4 by the way). The script then parses the output to ascertain whether a PRI is up or not.

The actual code to connect to the manager interface and execute the query is simply:

if( ( $astsock = fsockopen( $host, $port, $errno, $errstr, $timeout ) ) === false )
{
    echo "Could not connect to Asterisk manager: $errstr";
    exit( STATUS_CRITICAL );
}

fputs( $astsock, "Action: Login\r\n");
fputs( $astsock, "UserName: $username\r\n");
fputs( $astsock, "Secret: $password\r\n\r\n"); 

fputs( $astsock, "Action: Command\r\n");
fputs( $astsock, "Command: pri show spans\r\n\r\n");

fputs( $astsock, "Action: Logoff\r\n\r\n");

while( !feof( $astsock ) )
{
    $asttext .= fread( $astsock, 8192 );
}

fclose( $astsock );

if( strpos( $asttext, "Authentication failed" ) !== false )
{
    echo "Asterisk manager authentication failed.";
    exit( STATUS_CRITICAL );
}

This plugin is hard coded to English and expects to find Provisioned, Up, Active for a good PRI. For example, the Asterisk implementations that support the pri show spans command that I have access to return one of:

• PRI span 1/0: Provisioned, In Alarm, Down, Active
• PRI span 3/0: Provisioned, Up, Active

I’m actually running a slightly older version of Nagios at the moment, version 1.3. To integrate the plugin, first add the following command definition to an appropriate existing or new file under /etc/nagios-plugings/config/:

define command{
        command_name    check_asterisk_pri
        command_line    /usr/lib/nagios/plugins/check_asterisk_pri.php \\
             -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -w $ARG3$ \\
             -c $ARG4$ -n $ARG5$
}

where $ARG1$ is the Asterisk manager username and $ARG2$ is the password. $ARG3$ and $ARG4$ are the warning and critical thresholds respectively whereby if the number of available PRIs reaches one of these values, the appropriate error condition will be set. Lastly, $ARG5$ is the number of PRIs the plugin should expect to find.

NB: the command_line line above is split for readability but it should all be on the one line.

Now create a test for a host in an appropriate file in /etc/nagios/config/:

define service{
        use                             core-service
        host_name                       hostname.domain.ie
        service_description             Asterisk PRIs
        check_command                   check_asterisk_pri!user!pass!2!1!4
}

Ensure that your Nagios server has permissions to access the Asterisk server via TCP on the Asterisk manager port (5038 by default). If on a public network, this should be done via stunnel or a VPN for security reasons.

Lastly, you’ll need a user with the appropriate permissions and host allow statements in your Asterisk configuration (/etc/asterisk/manager.conf):

[username]
secret = password
deny=0.0.0.0/0.0.0.0
permit=1.2.3.4/255.255.255.255
read = command
write = command

The next version may include support for BRI and Zap FXO ports also. I also plan on a Cacti plug in to show the channels on each PRI (up – on a call, down, etc). In any case, updates will be posted here.

The plug in can be download from: http://www.opensolutions.ie/misc/check_asterisk_pri.php.txt

For those that don’t know, this feature has existing in KDE in multiple forms for some time. For example, pressing ALT-F2 opens the Run Command dialog and typing, for example:

php:fopen

will bring up PHP.net’s own search page. The same goes for the location bar in Konqueror.

By the way, other nice short cuts in the Run Command dialog include:

• gg: <keywords> for a quick Google search;
• wp: <keywords> for a quick Wikipedia search;
• dict: <keyword> for a quick dictionary look-up;
• man: <keyword> for a man page look-up;
• info: <keyword> for an info page look-up;
• rfc: <number> to be brought to the relevant RFC page;

Of course, entering a command will execute it and just entering a URL will open it in Konqueror.

Unfortunately there didn’t seem to be a lot of information out there on Promise’s SNMP MIBs so with a bit of playing about, I was able to dig out the ones I needed. The Nagios plug-in I wrote and am making available here will monitor the shelf via SNMP and alert on the following chassis issues:

• critical if any of the shelf’s disk states changes from “OK”;
• warning if the battery state changes from “FullyCharged”;
• critical if either of the PSU states change from “Powered On and Functional”;
• critical is any of the cooling devices (fans) change from “Functional”;
• critical if any of the temperature sensors’ states change from “normal”;
• critical if any of the drives go offline or are missing; and
• warning if any of the drives go into the rebuilding state or have their PFA flag set.

While this is specifically designed for a single M200i, it should be easily customisable for other models.

It can be downloaded from here (http://www.opensolutions.ie/). It will also appear on the development section of this site and Nagios Plugins.

OIDs Used

1.3.6.1.4.1.7933.1.10.2.1.1.1.8

The table of physical disk statuses.

.1.3.6.1.4.1.7933.2.1.7.1.1.14.1.1

The battery status.

.1.3.6.1.4.1.7933.2.1.4.1.1.2.1

The table of Power Supply Unit statuses.

.1.3.6.1.4.1.7933.2.1.3.1.1.3.1

The table of cooling device/fan statuses.

.1.3.6.1.4.1.7933.2.1.5.1.1.3

The table of temperature sensor statuses.

.1.3.6.1.4.1.7933.1.10.1.2.1.1.22.1

The number of drives that are offline.

.1.3.6.1.4.1.7933.1.10.1.2.1.1.23.1

The number of drives in the PFA status set.

.1.3.6.1.4.1.7933.1.10.1.2.1.1.24.1

The number of drives in rebuild status.

.1.3.6.1.4.1.7933.1.10.1.2.1.1.25.1

The number of drives that are missing.

# svn mkdir svn+ssh://user@host/srv/svn-repository/hosts/host1/etc \
         -m "Make a directory in the repository to correspond to /etc for this host"
# cd /etc
# svn checkout svn+ssh://user@host/srv/svn-repository/hosts/host1/etc .
# svn add *
# svn commit -m "Initial version of this host's config files"

IPMI Details

There are patches available for the Linux kernel to allow the IPMI information to be read via the lm_sensors project but I chose to avoid this (at least for now) as I’d have to schedule downtime to reboot the servers for a new kernel. It’d also ruin their uptime – most of the servers (serving many thousands of users daily) have almost two years of uptime. (The kernels are monolithic.)

Instead, I went with the already compiled in Linux IPMI Driver (see kernel source: Documentation/IPMI.txt) which is available in the ‘Character Devices’ menu. I specifically needed the following options for the Dells:

• drivers/char/ipmi/ipmi_msghandler
• drivers/char/ipmi/ipmi_devintf
• drivers/char/ipmi/ipmi_si

In order to read information from the IPMI, you need the ipmitool utility which is available on most recent Linux distributions or from here.

Lastly, I needed to create a character special file to interface with the IPMI:

mknod /dev/ipmi0 c 254 0

The sensor information was then available via:

# ipmitool sensor
Temp             | 30.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na
Temp             | 34.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na
Ambient Temp     | 16.000     | degrees C  | ok    | na        | 3.000     | 8.000     | 42.000    | 47.000    | na
...

Making IPMI Sensor Information Available via SNMP

I make the IPMI sensor information available over SNMP by adding the following to the snmpd.conf file:

# Monitor IPMI Temperature and Fan stats
exec    .1.3.6.1.4.1.X.1000 ipmitemp        /usr/local/sbin/ipmi-temp-stats
exec    .1.3.6.1.4.1.X.1001 ipmifan         /usr/local/sbin/ipmi-fan-stats

(Replace X above as appropriate.)

The scripts referenced are: /usr/local/sbin/ipmi-temp-stats:

#! /bin/sh

PATH=/usr/bin:/bin
STATS=/tmp/ipmisensor-snmp

printf "%f\n" `cat $STATS | grep Temp | cut -s -d "|" -f 2`

And /usr/local/sbin/ipmi-fan-stats:

#! /bin/sh

PATH=/usr/bin:/bin
STATS=/tmp/ipmisensor-snmp

printf "%f\n" `cat $STATS | grep FAN | cut -s -d "|" -f 2`

The file they reference is generated every 5mins (Cacti polling interval) via a cron entry in the file /etc/cron.d/ipmitool:

*/5 * * * * root /usr/bin/ipmitool sensor >/tmp/ipmisensor-snmp

After restarting SNMP and allowing the cron job to execute at least once, you can test the results via:

# snmpwalk -c <community> -v <version> <ip/hostname> .1.3.6.1.4.1.X.1000
SNMPv2-SMI::enterprises.X.1000.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.X.1000.2.1 = STRING: "ipmitemp"
SNMPv2-SMI::enterprises.X.1000.3.1 = STRING: "/usr/local/sbin/ipmi-temp-stats"
SNMPv2-SMI::enterprises.X.1000.100.1 = INTEGER: 0
SNMPv2-SMI::enterprises.X.1000.101.1 = STRING: "37.000000"
SNMPv2-SMI::enterprises.X.1000.101.2 = STRING: "39.000000"
SNMPv2-SMI::enterprises.X.1000.101.3 = STRING: "23.000000"
SNMPv2-SMI::enterprises.X.1000.101.4 = STRING: "36.000000"
...
SNMPv2-SMI::enterprises.X.1000.102.1 = INTEGER: 0
SNMPv2-SMI::enterprises.X.1000.103.1 = ""

Graphing This Information in Cacti

Finally, I graph this information on Cacti (see end of post for examples).

I am making six templates available here which can be imported into Cacti (these were generated using version 0.8.6j) for graphing the above:

1. Cacti graph template for Dell 1850 temperatures (see first image below);
2. Cacti graph template for Dell 2850 temperatures (see second image below);
3. Cacti graph template for Dell 1850 fan speeds (see third image below);
4. Cacti graph template for Dell 2850 fan speeds (see fourth image below);
5. Cacti host template for Dell 1850; and
6. Cacti host template for Dell 2850.

The last two templates available are host templates for Dell 1850s and 2850s (I’m sure they’ll work fine with 1950s and 2950s also). These templates include:

• Host MIB – Logged in Users;
• Host MIB – Processes;
• IPMI Fan Speeds (Dell x850) (from above);
• IPMI Temperatures (Cel) (Dell x850) (from above);
• ucd/net – CPU Usage;
• ucd/net – Load Average;
• ucd/net – Memory Usage;
• SNMP – Get Mounted Partitions (data query); and
• SNMP – Interface Statistics (data query).

Example graphs are shown below; they’re not the cleanest given the amount of information they contain but they serve my purposes.

© 2007 Barry O’Donovan. All text is licensed under a Creative Commons Attribution 3.0 License. All scripts and Cacti templates are licensed under the MIT License.

The last version can be found at http://www.pixelbeat.org/scripts/gcccpuopt along with a lot of other useful scripts and scripting examples here.

The conversation reminded me of a news bite I read on KDE.news about new Linux VoIP clients that are gaining momentum. One in particular looked very promising: Twinkle. The first version of Twinkle, 0.1, was only released last month but it’s already a formidable application when compared with KPhone.

Although Twinkleuses the cross platform application development framework known as Qt (which is also the foundation of KDE), it is only compatible with Linux’s audio system. Some of the features already completed include two lines, three-way conference calls, call redirection, DTMF sopport and the G.771 and GSM audio codecs.

Some obvious features that are currently missing but that the author plans to add include an address book, a history function to log incoming and outgoing calls, instant messaging and video support. So far I’m very impressed and I have already replaced KPhone with Twinkle.

The only negative comment I have to make, and it’s not really a reflection on Twinkle, is that although the author decided to use Qt it is really a shame he didn’t go the extra step and use the KDE application framework so that it would better integrate with that desktop environment and the other KDE PIM and networking applications. No doubt Michel de Boer, the author, has his reasons – perhaps he plans to extend Twinkle‘s compatibility to other operating systems.


#!/bin/bash

if [ $PROGRESS ]; then
  for (( i=0; i<30; i++ )); do
    dcop $PROGRESS setProgress $i
    sleep 1
  done
  dcop $PROGRESS close
fi


The purpose of Mikolaj's post was to suggest a method of regimenting work periods - e.g. 20 minutes on, 5 minutes off - using the above script and KAlarm, a personal alarm message, command and email scheduler. But, more than that, it shows off one of the many hiddens treasures of KDE: KDialog, which allows shell scripts to take advantage of some of the KDE widget set, and DCOP, KDE's Desktop COmmunications Protocol.

More information and a tutorial can be found at:

http://developer.kde.org/documentation/tutorials/kdialog/t1.html

In her own words:

I am most certainly not [undecided on this issue]. In response to your concerns about software patentability, I would like to reassure you that I am wholeheartedly opposed to this legislation. It will stifle innovation and prevent SME’s and individuals from having the chance to compete equally with the Microsoft’s of this world. You may rest assured that we will be fighting this directive (again).

As it currently stands, we now have eight of our sixteen (inc. Northern Ireland) MEPs committed to opposing^* software patentability with five yet to inform us of their position and three taking the matter under consideration. Optimistically, the final count could be as good as twelve or thirteen opposing this.

The next big task will be to ensure that all those opposing software patentability will actually turn up in parliament as an absolute majority will be required to defeat or amend the directive; this essentially means that any MEP who does not show up in parliament to vote will be effectively casting their vote in favour of the directive. What a wonderful democracy we have.

More information on the Irish campaign can be found at KDE.ie and at the Irish Free Software Organisation. The current status of the sixteen Irish MEPs is also available at KDE.ie and with more detail here.

^* by oppose I refer to an MEP being against the patentability of software ideas and business methods; this does not reflect whether an MEP is against the directive itself or would prefer to see it amended.