Sending SMS notifications with Gnokii on CentOS 6

I had a couple of Huawei USB UMTS/HSPA sticks gathering dust, so I decided to use them for SMS notifications. Below is a quick set of notes I took during the experiment.

Configuration

My setup:

  • CentOS 6.3 (64-bit)
  • GNOKII 0.6.30 (available from EPEL)
  • Huawei E160G and Huawei E176
  • Valid SIM card, PIN entry disabled

Plug in the USB stick, watch /var/log/messages. You should see something like this:

Jan 19 23:23:47 hal kernel: usb 2-2: new high speed USB device number 13 using ehci_hcd
Jan 19 23:23:48 hal kernel: usb 2-2: New USB device found, idVendor=12d1, idProduct=1003
Jan 19 23:23:48 hal kernel: usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Jan 19 23:23:48 hal kernel: usb 2-2: Product: HUAWEI Mobile
Jan 19 23:23:48 hal kernel: usb 2-2: Manufacturer: HUAWEI Technology
Jan 19 23:23:48 hal kernel: usb 2-2: configuration #1 chosen from 1 choice
Jan 19 23:23:48 hal kernel: scsi36 : SCSI emulation for USB Mass Storage devices
Jan 19 23:23:48 hal kernel: usb 2-2: USB disconnect, device number 13
Jan 19 23:23:54 hal kernel: usb 2-2: new high speed USB device number 14 using ehci_hcd
Jan 19 23:23:54 hal kernel: usb 2-2: New USB device found, idVendor=12d1, idProduct=1003
Jan 19 23:23:54 hal kernel: usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Jan 19 23:23:54 hal kernel: usb 2-2: Product: HUAWEI Mobile
Jan 19 23:23:54 hal kernel: usb 2-2: Manufacturer: HUAWEI Technology
Jan 19 23:23:54 hal kernel: usb 2-2: configuration #1 chosen from 1 choice
Jan 19 23:23:54 hal kernel: option 2-2:1.0: GSM modem (1-port) converter detected
Jan 19 23:23:54 hal kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
Jan 19 23:23:54 hal kernel: option 2-2:1.1: GSM modem (1-port) converter detected
Jan 19 23:23:54 hal kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
Jan 19 23:23:54 hal kernel: scsi39 : SCSI emulation for USB Mass Storage devices
Jan 19 23:23:54 hal kernel: scsi40 : SCSI emulation for USB Mass Storage devices
Jan 19 23:23:55 hal kernel: scsi 39:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Jan 19 23:23:55 hal kernel: scsi 40:0:0:0: Direct-Access     HUAWEI   MMC Storage      2.31 PQ: 0 ANSI: 2
Jan 19 23:23:55 hal kernel: sr1: scsi-1 drive
Jan 19 23:23:55 hal kernel: sr 39:0:0:0: Attached scsi generic sg3 type 5
Jan 19 23:23:55 hal kernel: sd 40:0:0:0: Attached scsi generic sg4 type 0
Jan 19 23:23:55 hal kernel: sd 40:0:0:0: [sdc] Attached SCSI removable disk

Each Huawei sticks presents itself as 2 separate USB modems: /dev/ttyUSB0 and /dev/ttyUSB1. I will use /dev/ttyUSB1 since SMS notifications are apparently only sent to the second port. The Micro-SD slot is reported as a SCSI device – not used here.

Now it’s time to configure Gnokii. I’ll send SMS as root, so I created directories under /root:

$ mkdir -p /root/.config/gnokii
$ mkdir -p /root/.cache/gnokii

Copy the default configuration file from /etc/gnokiirc to /root/.config/gnokii/config and add the following section:

# Huawei USB Stick
[phone_huawei]
model = AT
port = /dev/ttyUSB1
connection = serial

Issue a Gnokii command to verify that it works:

$ gnokii --phone huawei --identify
GNOKII Version 0.6.30
IMEI         : 333444555666777
Manufacturer : huawei
No flags section in the config file.
Model        : E176
Product name : E176
Revision     : 11.126.02.01.55

Sending SMS

OK, now for the real test – sending an SMS:

$ echo "SMS from Huawei" | gnokii --sendsms +31612341234 -r

If the SMS was sent correctly, gnokii exits with status 0. You can check that using the $? variable in your shell.

Receiving SMS

Incoming SMS are saved on the SIM-card memory, in memory slots starting at 0 (zero). To read the first (oldest) received message:

$ gnokii --phone huawei --getsms SM 0

The next one can be read using:

$ gnokii --phone huawei --getsms SM 1

… and so on.

Once you processed a message, you can delete it from the SIM-card:

$ gnokii --phone huawei --deletesms SM 1

There’s a lot of fun to be had with this setup – using simple SMS.

For interactive viewing of incoming SMS, use:

$ gnokii --phone huawei --smsreader

This will show new messages immediately.

Wrap-up

There’s lots more information to be found on the Gnokii Wiki.

My Huawei E160G turns out to have a SIM-lock on it. It would error out on most requests until I inserted a SIM of the correct network. Not all documented commands work:

$ gnokii --phone huawei --getlocksinfo
GNOKII Version 0.6.30
Error: Command called isn't implemented in model.

This makes troubleshooting quite a bit harder…

Nagios alerting

Next on my list is integration with Nagios – this is fairly simple; set up a Host Notification and Service Notification command that echoes a message to Gnokii. Voila: SMS alerting for Nagios ;-)

Process incoming SMS

Incoming SMS can be read using “gnokii --getsms“, but “gnokii-smsd” is a better option. It polls the USB modem regularly, and stores received messages in a database (PostgreSQL or MySQL). This makes it quite easy to use SMS from your own applications.

Have fun!

Workaround for Nagios check_linux_raid failure in RHEL / CentOS 6.2

I recently stumbled upon another Nagios plugin that no longer works with SELinux under RHEL / CentOS 6.2: check_linux_raid.

Just like the check_disk plugin, it has the nagios_checkdisk_plugin_exec_t SELinux type. As of May 2012, this problem has not yet been fixed.

The workaround is simple, as with the check_disk plugin:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib64/nagios/plugins/check_linux_raid

Or, for 32-bit systems:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib/nagios/plugins/check_linux_raid

Workaround for Nagios check_disk failure in RHEL / CentOS 6.2

After updating from EL 6.1 to 6.2, the Nagios “check_disk” plugin suddenly stopped working with “Permission denied” errors. This problem is related to the SElinux policy (you *are* running with SElinux enabled, aren’t you?).

By default, these AVC denials are not logged in /var/log/audit/audit.log which makes this problem harder to spot (if you want, you can enable all audit-messages by running semodule -DB).

There are at least two relevant entries in Bugzilla:

  • Bug 771245 – nagios-plugins-disk fails when checking /boot on RHEL6.2 boxes
  • Bug 768055 – SELinux silent denials of Nagios NRPE check of /boot

Fortunately, there is a simple workaround while we wait for an updated selinux-policy package. As root, do the following:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib64/nagios/plugins/check_disk

Or, for 32-bit systems:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib/nagios/plugins/check_disk

No need to restart anything; just wait until Nagios re-checks the service and the problem should be gone. Enjoy!

Twagios 2.0 – Nagios notifications revisited

In a previous blog post, I described how to use Twitter for Nagios notifications – dubbing it “Twagios”.

A couple of months later, Twitter stopped supporting basic authentication (username/password). This meant that the old (simple) way of sending notifications stopped working. In this post, I’ll explain how I replaced the old Twagios with a new script – “Twagios 2.0” ;-)

First of all, a big thank you to Jeff Miller for writing this excellent post on using the Python tweepy library to create a simple command line client. I simply followed Jeff’s instructions…

  1. Install the tweepy library
  2. Create a new OAuth registration at http://twitter.com/oauth_clients
  3. Create the new “Twagios 2.0” client
  4. Configure Nagios notifications

Install the tweepy library

I’m on CentOS 6.0. Assuming that you already have Python installed, the easiest way to get tweepy is through pip, the Python package manager:

  yum install python-pip
  pip-python install tweepy

Note: why name the package python-pip, and the binary pip-python? How intuitive ;-)

Create a new OAuth registration

I am assuming that you already created a separate Twitter account for sending out Nagios notifications – if not, read my old blog post. The next steps were taken from Jeff Miller’s blog:

Go to http://twitter.com/oauth_clients and log in with your “Twitter Bot” account. Register a nice name for your new script as a “client” with “read & write” permissions. Twitter should issue you with a “Consumer Key” and “Consumer Secret” for your new client.

Authorize access to your “Twitter Bot” account by replacing the CUSTOMER_KEY and CUSTOMER_SECRET values in the following temporary script:

  #!/usr/bin/env python

  import tweepy

  CONSUMER_KEY = 'paste your Consumer Key here'
  CONSUMER_SECRET = 'paste your Consumer Secret here'

  auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
  auth_url = auth.get_authorization_url()
  print 'Please authorize: ' + auth_url
  verifier = raw_input('PIN: ').strip()
  auth.get_access_token(verifier)
  print "ACCESS_KEY = '%s'" % auth.access_token.key
  print "ACCESS_SECRET = '%s'" % auth.access_token.secret

Run the script, open the “Please authorize” URL in your browser and confirm authorization for your “Twitter Bot” account. Twitter should now give you a PIN number. Enter this PIN number and the script should display an ACCESS_KEY and ACCESS_SECRET. We now have all the information successfully authenticate the new client with Twitter.

Create your new “Twagios 2.0” client

Create the actual “Twagios 2.0” script; replace the CONSUMER_KEY, CONSUMER_SECRET, ACCESS_KEY and ACCESS_SECRET with the proper values:

  #!/usr/bin/env python
  #
  # See: http://talkfast.org/2010/05/31/twitter-from-the-command-line-in-python-using-oauth

  import sys
  import tweepy

  CONSUMER_KEY = 'paste your Consumer Key here'
  CONSUMER_SECRET = 'paste your Consumer Secret here'
  ACCESS_KEY = 'paste your Access Key here'
  ACCESS_SECRET = 'paste your Access Secret here'

  auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
  auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
  api = tweepy.API(auth)
  api.update_status(sys.argv[1])

Done! Send your first tweet:

  chmod 755 twagios
  ./twagios "Hello World"

Configure Nagios

The notification commands describedin my old post should be changed as follows:

  ### Twitter ###

  define command{
        command_name    host-notify-by-twitter
        command_line    /usr/local/bin/twagios "@MyTwitterAccount $HOSTALIAS$ is $HOSTSTATE$. $HOSTOUTPUT$. Time: $SHORTDATETIME$"
  }

  define command{
        command_name    notify-by-twitter
        command_line    /usr/local/bin/twagios "@MyTwitterAccount $SERVICEDESC$ @ $HOSTNAME$ is $SERVICESTATE$. $SERVICEOUTPUT$. Time: $SHORTDATETIME$"
  }

Note: Replace “@MyTwitterAccount” with your actual Twitter account so your Twitter Bot account can send you @mentions.

You could even have it send DM’s by prefixing the message with “d “, for example:

  /usr/local/bin/twagios "d @MyTwitterAccount $HOSTALIAS$ is $HOSTSTATE$. $HOSTOUTPUT$. Time: $SHORTDATETIME$"

Update 2011.12.05 – message length check

As suggested by @erik_mol on Twitter, the above script lacks a check for message length (140 characters max.):

Twagios script needs minor tweak; s = sys.argv[1] api.update_status(s[0:140]). Saves other readers headache, thanks

As message length is indeed important, I have also added some sample substitutions (“WARNING” becomes “WARN” and so on), reducing message length where possible.

  #!/usr/bin/env python
  #
  # See: http://talkfast.org/2010/05/31/twitter-from-the-command-line-in-python-using-oauth

  import sys
  import tweepy
  import string

  CONSUMER_KEY = 'paste your Consumer Key here'
  CONSUMER_SECRET = 'paste your Consumer Secret here'
  ACCESS_KEY = 'paste your Access Key here'
  ACCESS_SECRET = 'paste your Access Secret here'

  auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
  auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
  api = tweepy.API(auth)

  # Process the commandline argument, replace words etc. to shorten the message
  s = sys.argv[1]
  s = string.replace(s,"WARNING","WARN")
  s = string.replace(s,"PROBLEM","PROB")
  s = string.replace(s,"CRITICAL","CRIT")

  # Send the message, 140 characters max.
  api.update_status(s[0:140])

Enjoy the script – happy Sinterklaas everyone ;-)

RHCA Exams: Two down, three to go!

As an IT professional, I find that certification has become more important over the years. Maybe this has to do with the economic climate – prospective customers and employers are more likely to talk to you if you have a couple of certifications on your resume. In my opinion, certifications that are based on multiple-choice exams offer little value – they merely test your ability to remember factoids.

The Red Hat certification exams are performance-based, so you really need to know your stuff and be able to apply it under considerable time pressure. This is why Red Hat certifications are received so well by customers and employers.

I’ve been a Red Hat Certified Engineer (RHCE RHEL4) since 2005. I’m now aiming for their highest certification level offered, Red Hat Certified Architect (RHCA). The RHCA certification requires you to pass 5 Expertise Exams on top of your RHCE certification; not an easy task.

In May 2009, I took my first Expertise exam, RH423 / EX423 (Directory Services and Authentication). In november 2010, I took one of the hardest exams in the RHCA track: RH442 / EX442 (System Monitoring and Performance Tuning). And boy, was it tough! I barely had 3 minutes left before the 4-hour exam was over and we had to “put down our keyboards” ;-)

Since the exams are subject to strict NDA, I cannot say anything about the content of the actual exam. You can look up the Exam Prep Guide for each Expertise on Red Hat’s website for a list of subjects covered in each course and exam.

So, what can you do to maximize your chance of passing the exams?

  1. Make sure you have plenty of actual experience with Linux
  2. Take the 4-day instructor-led course (usually offered as a bundle with the exam)
  3. Make sure you get plenty of sleep before the exam ;-)

I took the RH300 course for my RHCE RHEL4, and I plan to re-take the course for my upcoming RHCE RHEL6 renewal. That’s how useful I think the courses are!

The courses are jam-packed, but fun. I usually discover a couple of new ways to accomplish things under Linux – you can’t have enough tools in your Linux toolbox! The group discussions also add a lot of value – you’ll learn a lot from other people’s experience, usually involving breaking things in spectacular ways ;-)