Using Nagios from an Android Phone

I got an Android phone in the last year, and started looking in earnest for a Nagios client for it. With a Nagios client, you can read what the current status is of your systems in Nagios.

There are several available; the two most often mentioned are NagRoid and NagMonDroid. However, neither one of these worked for me, and there are indeed others that were good.

All of the clients use the same basic method to get data from Nagios: scrape the data from a web page. The biggest problem comes when that web page is not available – or is incorrect. Most of these applications request a URL, but sometimes are unclear as to what URL they want exactly. Add to that the fact that Nagios changed its URL structure slightly between versions and it gets even more complicated.

To discover what was happening, I used tcpdump to watch the accesses to the web server from the Nagios clients, as well as watching the Apache logs. By doing this, I was able to discern what URLs were being loaded.

Here are some of the URL paths being looked for by the various clients:

  • /cgi-bin/tac.cgi
  • /cgi-bin/status.cgi
  • /cgi-bin/nagios3/statuswml.cgi?style=uprobs
  • /cgi-bin/nagios3/status.cgi?style=detail
  • /cgi-bin/nagios3/status.cgi?&servicestatustypes=29&serviceprops=262144

Further complicating matters in my case was the fact that any unrecognized URL was massaged (via mod_rewrite) into serving the main Nagios page via SSL.

However, by using mod_rewrite it was possible to rewrite the old /cgi-bin paths to a newer /cgi-bin/nagios3 path, and things started working.

In the case of the statuswml.cgi file, Google Chrome wanted to download the resulting file instead of actually using it somehow.

The main choices for Nagios clients on Android are these:

I have gone with aNag – it has a nice interface, good use of notification, and worked without trouble once the URL was fixed up. Several of the others never did work right – or they gave no indication that they were working right. In the case of jNag, it also requires a modified Nagios server and the installation of mkLivestatus. aNag was the one that was easiest to work with and get working.

aNag does use a mostly text-based format to show data, but it has the ability to manipulate services as well as one-button access to the web interface directly.

A Statistical Analysis of Android Issues

I was recently researching an issue with Android phones – the oft-requested ability to record a phone call – and found that this has been an issue in Android since March of 2009 and remains classified as “New.” In fact, most of the issues in the top 1000 (according to users) remains classified as new and has not been allocated to any developers.

Thus, I started wondering about the various Android issues and their relative importance to users and developers. I downloaded the list of the top 1000 issues (in CSV format) – according to the number of stars – and analyzed these results.

Here is what I found out:

  • 63% of issues are more than one year old (12% of issues are over two years old!)
  • 86% of issues are listed as “new” (instead of “assigned” or “needsinfo” or others)
  • 10% of issues are assigned to a person
  • Average age of issues is 431 days (1 year, 2 months)
  • Average defect age is 457 days (1 year, 3 months)
  • Average enhancement request age is 543 days (1 year, 6 months)
  • Reviewed items were the oldest on average, with reviewed defects at 550 days and reviewed enhancements at 749 days.

When you rank the items by the number of stars (user importance) per day (age) some very interesting things come out. The most important issues in this ranking are the following:

  1. Change refund time in Android Market (issue #13116) – 32 days old
  2. Arabic Language Support (issue #5597) – 386 days old
  3. Nexus S reboots during an active call (issue #13674) – 8 days old
  4. Ability to limit Internet access (issue #10481) – 149 days old
  5. IPSEC VPN compatible with Cisco VPNs (issue #3902) – 484 days old
  6. Poor browser performance (issue #13404) – 19 days old
  7. Google Docs support on Android (issue #1865) – 714 days old

These items show one of two things – probably both – that either what users think is important is irrelevant to Google, or alternately, that the items are acted on and the issues tracking list ignored. People commenting on the issues are routinely asking where the Google responses are.

Another interesting item came up during statistical analysis: not one item (in the top 1000) which was listed as requested by a user or by a developer was listed with a status of Assigned or with a status of Reviewed. There were other items, but these were not listed as requested by either a user or a developer – and many of these were assigned or reviewed (or, indeed, Unassigned). I can only guess at the true meaning of this; it suggests that Google only acts when an issue comes from within Google.

In all, this statistical exercise would have been much more exciting if it weren’t for the disappointing results. I did check the main page to see if Google’s main page for Android in Google Code was obsolete; no such statement was anywhere to be found.

Oracle Sues Google Over Java on Android

Oracle – now having purchased Sun – has sued Google over their custom Java virtual machine for the Android mobile platform. In doing so, Oracle has sent reverberations throughout the open source and Java communities.

Google took the Java APIs and enhanced and changed them – then created a virtual machine (called Dalvik) which runs a custom format executable. This was part of the Android software when it was introduced in November 2007, and there were many complaints about Google’s treatment of Java – including complaints from Sun itself. Google’s response at the time to Sun’s complaints was:

Google and the other members of the Open Handset Alliance are working to help solve fragmentation and supporting the developer community by creating Android, a mobile platform that responds to the needs of the developers, has the backing of industry leaders, and will be available as open source under a nonrestrictive license.

To break that statement down, Google was saying:

  • The Open Handset Alliance (not the Java Community Process or JCP) should be the Java stewards for mobile Java.
  • Android (and Android Java) responds to the needs of the developers.
  • Android is backed by industry.
  • Android is available as open source.
  • Android is available under a nonrestrictive license.
  • Java 2 Mobile Edition (J2ME) has none of these capabilities.

Don’t miss the fact that Google created the Open Handset Alliance at the same time, and serves mainly as a source for Android – though it has in recent days been seen as useless by some.

Sun (now Oracle) has had a mobile version of Java (known as J2ME) since before Android existed – but Google bypassed it (and the Java Community Process or JCP) when it created its own JVM. Dalvik executables, in fact, are created from Java binaries, thus involving Java itself in the process of creation and development.

It appears that Google’s Android Java implementation was a direct attack on the JCP and on J2ME. To use J2ME, Google would have had to license it, as it was not available under a license that would have allowed commercial closed-source development: it was under the GPL, but without the classpath exemption that the J2SE had. Because of this lack of the classpath exemption, any development on the standard J2ME platform would have to be released as source code under the GPL.

This action by Oracle fits perfectly into its public persona: consider that Sun’s Chief Open-Source Officer, Simon Phipps, was not even offered a position at Oracle at all. He is or was on the advisory boards for OpenSolaris, OpenJDK, and OpenSparc. Other distinguished Sun engineers have left, including Kohsuke Kawaguchi (chief developer of Hudson), Charles Nutter and Thomas Enobo (both lead developers of JRuby), Tim Bray (Director of Web Technologies – which includes Java and JRuby), and James Gosling (creator of Java). It is notable that all of these people except Simon Phipps are luminaries in the Java realm at Sun. It is as if the Java engineers left wholesale once Oracle was about to take over.

Coverage of the lawsuit has been extensive. Stephen Shankland over at CNet has a story about why Oracle may have chosen to sue. Stephen O’Grady over at RedMonk may have one of the best in-depth analyses of this conflict out there. Groklaw has committed to following the lawsuit through the courts, and has an excellent introductory piece on the lawsuit. Steven Vaughn-Nichols suggests that this lawsuit is only the beginning, and that JBoss, Apache Jakarta, and the JCP better watch out (though I disagree).

From when Google introduced Android and its associated virtual machine, Dalvik, Stefano Mazzochi had one of the most complete explanations of what Google was doing and its implications.