PHP (21)


Updates!

I’ve just finished packaging, uploading and releasing the latest versions of jNag. These include a new server component, and updates to all the clients. Read on for the details:




jNag 0.5 pre-release

This release marks a major change in the codebase, and is pretty much a complete rewrite. jNag now works on a client / server model with a small plugin that sits on your Nagios install as the server and a pure HTML5 / javascript client talking to that server backend via JSON calls. The client can run on the same server as the um…server, or it can be somewhere else entirely (like running natively on your handset)

From a user perspective this means that things should be slightly quicker, and for future releases native apps connecting to the jNag backend will be a possibility. However, there’s slightly more setup involved.

prerequisites:
Nagios (only tested on 3.2, may work perfectly well on other versions for all I know)
livestatus

You’ll need to extract all the files into your nagios web root, then edit the configuration under jNag/server/config.php to reflect your setup. The configuration should be fairly self explanatory.

Once your server is configured, launch the client by going to /jNag/client in a browser. You should be prompted to enter a data url. This needs to be the url of /server/returndata.php. So, if you’ve installed jNag into ‘http://yourserver.com/nagios/jNag’ you need to set the data_url to ‘http://yourserver.com/nagios/jNag/server/returndata.php’

This is pre-release software! Whilst it works perfectly fine on my setup, I have no doubt it’s riddled with bugs at the moment!

I’m already working on showing pnp graphs in jNag for the next release, and some other goodies as well, this is just a taster of the new architecture and functionality.

[download id=”1″ format=”1″]




jNag 1.4.1 released

Minor ‘point’ release of jNag offering the following features:

  • security enhancements suggested in this comment
  • Faster initial problem polling when first loading the app
  • debug option (run jNag with the debug variable set, ie: http://yourserver/jNag/?debug=true)

[download id=”2″ format=”1″]

And, in other news….

I’m currently working on a completely re-written version of jNag that runs entirely in javascript on the client side, with a small server side plugin based on livestatus providing the data. It’s much faster, and offers the possibility of native apps for all major mobile devices (iPhone, android, blackberry, palmos) based on the phonegap platform. Should be ready for release in the next few days, I’m just having some fun with localStorage at the moment…




jNag 0.4 released

jNag 0.4 is out now!

This release allows you to select the livestatus backend instead of statusjson if you like.

The problem list also now really auto refreshes! (in previous versions the count on the main page auto-refreshed, but once you went into the problems page itself you had to manually refresh)

I’ve also tidied up some code and moved things around to make the whole package a bit more coherent.

Demo here

Download here




jNag ‘coming soon’ features

I’ve not really had chance to work on jNag over the last couple of days, but I managed to snatch an hour at lunch yesterday to refactor some code and do some architectural changes in preperation for 0.4.  The major new feature for this release will be a ‘livestatus‘ backend in addition to the current statusjson system.  You’ll be able to switch between the two by a simple config change.

Other planned features include:

  • Multiple server support
  • Configuration page (for jNag)
  • Nagios control page (restart Nagios, reschedule checks etc)

If there’s any other features you’d like to see added, feel free to comment.  And look out for jNag 0.4 in the next couple of days.




jNag 0.2 released

Yesterday I released jNag, my new mobile web interface for the rather spiffy Nagios network monitoring tool.

Today I’ve updated it with some new features:

  • You can now see host problems as well as service problems
  • Acknowledged problems now don’t show in the main list on the front screen
  • (this is the major one) you can now acknowledge problems right from jNag!

download it here

demo is here

Here’s a screenshot of the new ‘acknowledge function in use:




jNag – mobile interface for Nagios

I recently became aware of Jquery Mobile, a new framework from the group behind the rather excellent jquery, that focuses on mobile development. Using the framework you can quickly and easily produce a web app that’s tailored for mobile devices and offers a consistent user experience across a range of mobile platforms.

I decided I needed a little project to get to grips with how JQuery mobile works and, since I’d spent an afternoon at work this week setting up the rather excellent Nagios (a network monitoring server) I thought I’d have a go at producing a mobile interface for it.

Nagios helpfully provides a way of getting JSON formatted data about it’s current status via a cgi script (statusjson.cgi) so it was simply a case of parsing that data and outputting it via the jquery mobile stuff.

Here’s what I came up with: jNag (apologies for the name, it’s late).  It’s a bit rough and ready at the moment, but it can display alerts (warning / critical), allow you to browse through your tree of devices and drill down to view service output.  If you combine it with the rather excellent NagDroid to give you notifications you have a full mobile admin suite.  Not bad for a few hours work.

download here (extracted files need uploading to your nagios webroot)

There’s a demo here (best viewed on an Android device or  iPhone)

here’s how it looks on my Desire HD




WP Akismet plugin behind proxy

The new HTTP Api in wordpress 2.9 is fantastic, it standardises http requests and allows you to define a proxy through which all http requests are routed.  Useful if, like me, you run a wordpress server on a corporate network.

You can configure your proxy server by adding the following lines to your ‘wp-config.php’

define('WP_PROXY_HOST', '192.168.250.1');
define('WP_PROXY_PORT', '800');
define('WP_USEPROXY','TRUE');

However there’s currently one problem with the default installation of wordpress when it comes to proxy support. Akismet (the spam filtering plugin) Doesn’t work behind the proxy. No matter what you put in for your proxy settings you’ll be told ‘unable to connect’.

The reason is that Akismet uses a ‘raw’ socket connection to do its http requests, rather than the spiffy new API. So, here’s how to fix it:

you need to edit the file ‘/wp-content/plugins/akismet/akismet.php’.

search for the function ‘akismet_http_post’ and replace the entire function (you can just rename the old function) with my newly crafted one:

function akismet_http_post($request, $host, $path, $port = 80, $ip=null){
        global $wp_version;
	$akismet_version = constant('AKISMET_VERSION');
        $args = array(
             'method'=>'POST',
             'user-agent'=>"User-Agent: WordPress/$wp_version | Akismet/$akismet_version",
             'body'=>$request
        );
         $url = "http://".$host.$path;

         if( !class_exists( 'WP_Http' ) )
         include_once( ABSPATH . WPINC. '/class-http.php' );
	 $http_request = new WP_Http;
         $http_response = $http_request->request($url,$args);
         if( is_wp_error( $http_response ) )
              return;
         $response[0] = $http_response['headers'];
         $response[1] = $http_response['body'];
	return $response;
}

And voila, working spam detection behind a proxy.




Joomla Hack: autofill subject line on contact email

So, imagine you have a Joomla site containing lots of pages about…well, anything really. It’d be nice if you could have a ‘request info’ link on each page so users could send you an email with a pre-generated subject line about that page, so you can parse emails (either manually or using some kind of automatic system) coming from the site.

eg: your site has seperate pages about ‘product A’ and ‘product B’. you want a link on ‘product A’s’ page that sends you an email with the subject line ‘yoursite.com: product A enquiry’ and the same for product B.

I can’t find any way of doing this ‘properly’ in Joomla, so here’s a hack I came up with. What it does basically is take a variable from your URL and put it into the subject box. So you can setup a link to ‘http://yoursite.com/contact-us?subject=test subject’ and the contact email form will automagically have the subject line filled in with ‘test subject’.

First up, setup a contact to send the emails from (you’ve probably done this anyway if you have a ‘contact us’ page).

Now publish that contact using the ‘contact’ view under something like yoursite.com/contact-us

now here’s the hack:

open up “components/com_contact/views/contact/tmpl/default_form.php”

the line you’re looking for is this one (it’s line 50 in my copy of the file)

change that to this:


The additional line uses the JRequest class to get the value of our ‘subject’ variable. Then we simply write that into the subject field. We also set a default value ‘website enquiry’ so if the subject variable is unset we have a nice default subject line instead of a blank box. using JRequest::getWord to retrieve the variable means our input is automatically filtered to strip out any html / javascript injection attempts.

you can now set up links anywhere in your site to ‘contact-us?subject=your subject’ to automatically fill out the subject line.




PHP: clean up your includes!

If you’ve ever worked on any kind of PHP framework, you’ll likely know the pain that a misplaced ‘space’ in one of your includes can cause.  For the rest of you imagine this scenario:

To load a page in my framework, I have an index.php that loads in a ‘core.php’ (which isn’t web accessible for security purposes) which itself then loads in a long (20 or so) list of included files which make up my framework.  So, my core.php might look like this:

require_once("database.php");
require_once("mail.php");
require_once("something_else.php");
etc
etc
require_once("page_loader.php");
send_headers();
load_page($page_id);
send_footers();

which is lovely, keeps all the functionality of the framework nice and segregated.  However, if one of those included files actually outputs anything to the screen, it can cause all sorts of issues, especially if our ‘send_headers’ function is sending our actual HTML headers…. in this case, anything output to the screen before our HTML headers are sent can really cock things up. Even worse, trying to track down where the output is coming from can be a nightmare when you have a large number of included files.

After a bit of thinking I stumbled across the (probably) blindingly obvious way round this without spending hours debugging and trying to track down which included file is the culprit:

good old fashioned output buffering!

by doing this:

// start buffering
ob_start();

require_once("database.php");
require_once("mail.php");
require_once("something_else.php");
etc
etc
require_once("page_loader.php");

//stop buffering, discard buffer contents
ob_end_clean();

send_headers();
load_page($page_id);
send_footers();

we ensure that anything output by the included files is buffered, then discarded before we actually start outputting stuff.

lovely.