thoughts of a doug

I am using two of my distributions as tests for using Module::Build instead of Module::Install. So far they have only been released as development versions, but I hope to get them out as actual releases. So far I have chosen not to generate any Makefile.PL in the distributions, but I think I will in the actual releases. I love how easy Module::Install is to use, but I have to agree with the arguments for Module::Build and that it is written in Perl and doesn’t rely on an outside build system that is really not needed at all for pure-Perl modules like my current distributions are.

Recently I have been adding my own bug list and todo list to the RT queue of my CPAN modules to track them and help me remember over a longer period of time. I also figure that if they are visible to everyone, perhaps someone may help fix or add a feature.

I usually get e-mails about my Nagios::Plugin::OverHTTP asking about little things being added here and there. The last e-mail I got was from Peter van Eijk asking for support for performance data. I looked over the code and realized that it really needs some refactoring before I can easily add support for performance data, and so I am currently hung up on that before the feature will get added.

My current thoughts on support for getting performance data from the remote page would be to just scrape it from the standard plugin output, which is supported as the body:

PLUGIN OK - Good to go! | time=0.012s;1;10;10;0

I was also thinking about how to add support for receiving as headers, since the other supported aspects of the plugin may be transmitted as headers. My current thoughts are for a header named X-Nagios-Performance which would hold the name=value pair, separated by spaces like the normal plugin and would also allow more than one header with the data to be present:

X-Nagios-Performance: time=0.012s;1;10;10;0
X-Nagios-Performance: count=2;;;50;0 other=4;;;4;0

For Nagios::Plugin::OverHTTP itself, since the remote plugin can provide critical and warning thresholds, I was thinking of allowing for actually changing the status based on that to be made optional by default (because if the remote plugin said the status was OK but yet a performance metric it sent said that it should really be in a WARNING state, by default Nagios would have kept that as OK so I believe that my plugin should honor that as well by default). New options for the plugin would be:

--warning name=threshold
--critical name=threshold
--use-transmitted-thresholds
--override-transmitted-thresholds

The last option --override-transmitted-thresholds would cause the performance data written as the plugin’s output to be changed to match the thresholds given as the plugin’s options. This means a plugin with the given options --override-transmitted-thresholds --critical time=4 would cause the performance data to say time=0.012s;1;4;10;0 instead of time=0.012s;1;10;10;0 (note that this setting does not affect the decision of the final status code).

I have just uploaded a new module to the CPAN: Test::Override::UserAgent. This is geared toward developers that use LWP::UserAgent in their modules and want to easily test their code without having a live Internet connection or starting up a test server to make requests against. Just about every single module I have on the CPAN uses LWP::UserAgent and makes requests against live servers (usually they are doing web scraping). Before I was using Test::MockObject, but that was tedious at best.

The goal of Test::Override::UserAgent is to be able to write response overrides easily. The module allows for the author to create a class consisting of only definitions for overrides so the override definitions do not have to be repeated in each test file. An example override class would look like:

package t::CustomUA;
 
use 5.008;
use Test::Override::UserAgent for => 'configuration';
 
# Disable live requests (the default, anyhow)
allow_live(0);
 
override_request
  host => 'localhost',
  path => '/test',
  sub {
    return [200, ['content-type' => 'text/plain'], ['Test response']];
  };
 
1;

This will cause requests that have a host of localhost and a path of /test to get a response back of text/plain with the Test response body. This configuration can then be used in a test file:

#!perl -T
 
use 5.008;
use Test::More tests => 1;
use t::CustomUA;
 
use My::Module; # Your awesome module to test
 
my $object = new_ok 'My::Module';
 
# Your module has a way to set the user agent it uses
t::CustomUA->configuration->install_in_user_agent($object->user_agent);
 
# Perhaps your module has no way to set the user agent
# or there is something down stream that uses a user agent.
my $scope = t::CustomUA->configuration->install_in_scope;
 
# Do tests that make requests by LWP::UserAgent
 
# End the scope override
undef $scope;

I have published my interface to the University of South Florida online directory to the CPAN as WWW::USF::Directory. This is a start to my USF-oriented modules to go up on the CPAN for public use. This module allows you to interact with the USF online directory. It can be used to make a simple directory repeater like so:

#!/usr/bin/perl
 
package Directory;
 
use 5.008;
use strict;
use warnings 'all';
 
use base 'CGI::Application';
 
use JSON 2.00; # The API was changed
use Try::Tiny;
use WWW::USF::Directory;
 
sub setup {
	my ($self) = @_;
 
	# Create a directory object for use later
	$self->{directory} = WWW::USF::Directory->new(
		include_faculty  => 1,
		include_staff    => 1,
		include_students => 0,
	);
 
	# Start in search mode, which is the only mode
	$self->start_mode('search');
	$self->run_modes(search => 'search');
}
 
sub search {
	my ($self) = @_;
 
	# Hold the results and response
	my (@results, $response);
 
	# Set the header to specity JSON
	$self->header_add(-type => 'application/json');
 
	try {
		# Search the directory
		@results = $self->{directory}->search(
			name => scalar $self->query->param('name'),
		);
 
		foreach my $result (@results) {
			# Change the ::Directory::Entry object into a hash of its attributes
			$result = _moose_object_as_hash($result);
 
			if (exists $result->{affiliations}) {
				$result->{affiliations} = [map {
					_moose_object_as_hash($_);
				} @{$result->{affiliations}}];
			}
		}
 
		# Return the JSON-encoded results to print
		$response = JSON->new->encode({
			results => \@results,
		});
	}
	catch {
		# Get the error
		my $error = $_;
 
		# Return a JSON with the error
		$response = JSON->new->encode({
			error   => "$error",
			results => [],
		});
	};
 
	# Return the response
	return $response;
}
 
sub _moose_object_as_hash {
	my ($object) = @_;
 
	# Convert a Moose object to a HASH with the attribute_name => attribute_value
	my $hash = { map {
		($_->name, $_->get_value($object))
	} $object->meta->get_all_attributes };
 
	return $hash;
}
 
1;
 
package main;
 
use 5.008;
use strict;
use warnings 'all';
 
# Start and tun the application
Directory->new->run();

This will actually be added as an example in the next release. You can run this as a CGI and use the name param to pass what to search for, or run it from the command line with name="Name".

I am going to be publishing several of my Perl 5 modules that relate to the University of South Florida systems to the CPAN. This will allow anyone to use the modules as they please. I am planning on putting them in the namespace WWW::USF::*. I know that USF may be ambiguous, but feel it is appropriate since USF’s domain is usf.edu.

This is mostly an update to my previous post on my HP Pavilian tx 1000 issues. As time goes on, the laptop won’t boot up more. Today was the worst of all, though. I have determined that the problem is the same that lots of other people are having, which is where the nVidia GPU is becoming unseated from the motherboard, causing the BIOS not to POST.

So lately when I used my HP Pavilian tx 1000 (the complete part number is GD617AV) it makes me sad because there are two big issues with it:

1. Seemingly randomly (seems mostly when there is high network usage) the wireless network will no longer function until I reboot the laptop. This issue has persisted through multiple Windows installs and even in Ubuntu.
2. Sometimes the laptop will just not turn on. When I turn it on, the lights come on and the fan spins up, but then the display will just stay blank forever and there is no hard drive activity. I am not sure what the cause of this is, but I don’t think it is the hard drive, because the only way to get it to start up again is to remove the battery and reinsert the battery.

This just disappoints me and makes me want to try and pawn it off to someone else and get a new laptop. Does anyone else experience the same issues and/or know a fix?

In the newest version of Nagios-Plugin-OverHTTP (0.12) that was just pushed out to the CPAN, support for a new header was introduced, thanks to Alex Wollangk. The header is X-Nagios-Information and is used to contain the message for the plugin check. Why would this be wanted? Well, if added to a page, the page itself can serve a dual purpose: to accessible to a user and be a Nagios check. Also because of this, I have also added the option to customize the HTTP verb to use when making the request (like using the HEAD verb on such a page).

This could be used so that when a HEAD request comes from a specified IP address, the page can do some sort of self-check and output the results in the headers and provide back no body. This would allow for a very wide-range of live checks on a web site, giving up-to-date information regarding areas of the website they you would not notice until a user pointed out to you, allowing it to be fixed before anyone even notices.

A new release of Nagios::Plugin::OverHTTP was just pushed to the CPAN. This release brings no new features, but does change what is installed. The check_over_http script is now no longer automatically installed to the bin. Also when trying to get the plugin to work under ePN in Nagios, I discovered that if some spaces are at the end of the command line arguments, there is an undef loaded into the @ARGV variable which makes Getopt::Long give a warning, which then causes ePN to abort the plugin. I added some code into the check_over_http plugin distributed with my package that will work around this issue and adds a comment to tell Nagios to load the plugin under ePN. May the new plugin bring you faster service checks!