The main thing with non-blocking is that if you want to use something that is blocking, it is harder to use that in a non-blocking environment unless you can shove that blocking behavior into a background thread and put an event wrapper around it. Also, a non-blocking module can always be used in a blocking way, so I think this makes it a win-win.

Note: By “default to non-blocking” I mean that they can behave in a non-blocking way, so the module can behave both blocking and non-blocking.

Anyhow, after splitting the repository into two separate distributions, Jozef uploaded a TRIAL and then granted me co-maintainer status on the Net-TacacsPlus distribution and I uploaded the new distribution, as well as the new POE-Component-Server-TacacsPlus distribution.

Nothing on the CPAN should be affected by this distribution split, but any code on the DarkPAN should be fine as long as the dependencies are marked on the modules they require instead of the base module on the distribution they depend on.

CPAN::Reporter: Test::Reporter: error from 'Test::Reporter::Transport::Metabase::CPANTesters:'
fact submission failed: Can't connect to metabase.cpantesters.org:443 (certificate verify failed) at C:\strawberry\perl\site\lib/Metabase/Client/Simple.pm line 111
...
        Test::Reporter::Transport::Metabase::CPANTesters::send('Test::Reporter::Transport::Metabase::CPANTesters=HASH(0x7a932b8)', 'Test::Reporter=HASH(0x62cb790)') called at C:\strawberry\perl\site\lib/Test/Reporter.pm line 279
...

Simply modify your CPAN::Reporter configuration to use the standard Metabase transport with the CPAN Testers metabase URI. Here is a short script you can run to automatically update your configuration:

#!/usr/bin/env perl
 
use 5.006;
use CPAN::Reporter::Config;
 
my $config_file = CPAN::Reporter::Config::_get_config_file();
my $config = CPAN::Reporter::Config::_open_config_file();
 
my ($class, %args) = split m{\s+}mosx, $config->{_}->{transport};
 
if ($class eq 'Metabase::CPANTesters') {
    print "Modifying configuration file transport line from\n", $config->{_}->{transport}, "\n";
    # Correct the transport information
    $class = 'Metabase';
    $args{uri} = 'https://metabase.cpantesters.org/api/v1/';
    $config->{_}->{transport} = "$class " . join q{ }, %args;
    print "to\n", $config->{_}->{transport}, "\n";
    # Write the configuration
    $config->write($config_file);
    print "Done\n";
}
elsif ($config->{_}->{transport}) {
    # Modification does not look necessary
    print "Leaving transport configuration set to\n", $config->{_}->{transport}, "\n";
}
else {
    # Modification does not look like it should occur
    print "Not modifying configuration without transport directive\n";
}
 
exit 0;

In order to be fully capable of submitting reports through CPAN::Reporter, be sure to have the following modules installed:

IO::Socket::SSL
Mozilla::CA

For a full uninstall of the hypothetical distribution, please see the UNINSTALL file now included with the distribution.

There were a few blog articles where this change caught people by surprise in that submissions to the CPAN Testers Metabase failed (due to metabase.cpantesters.org using a self-signed certificate). Because metabase.cpantesters.org uses a self-signed certificate, simply installing Mozilla::CA, which is a bundle of all the trusted CAs by Mozilla, will not correct the submissions failures (plus you have to install a few other modules). The typically error you will see once you have libwww-perl-6.00 install is as follows:

CPAN::Reporter: Test::Reporter: error from 'Test::Reporter::Transport::Metabase:'
fact submission failed: Can't connect to metabase.cpantesters.org:443 (certificate verify failed) at C:\strawberry\perl\site\lib/Metabase/Client/Simple.pm line 111

You may also see the following error if you do not have IO::Socket::SSL installed:

CPAN::Reporter: Test::Reporter: error from 'Test::Reporter::Transport::Metabase:'
fact submission failed: Can't connect to metabase.cpantesters.org:443 (Crypt-SSLeay can't verify hostnames) at C:\strawberry\perl\site\lib/Metabase/Client/Simple.pm line 111

As a work-around for this problem (without just disabling certificate checking or other environment changes) I wrote two classes that subclass Metabase::Client::Simple and Test::Reporter::Transport::Metabase that make them specific to submitting to the CPAN Testers Metabase and bundle the metabase.cpantesters.org certificate and check the certificate against the bundled one. Having a module where a certificate is bundled may or may not be what CPAN Testers Metabase wants, which is why I do not have any intentions on actually publishing this distribution. If you are interested in looking at it, you can view it as Github Gist 867743 (using the download button at the top results in the distribution tarball).

The premise is to subclass the Metabase transport to set the uri to be the CPAN Testers Metabase URI by default and to set the client to my client subclass. The client subclass simply wraps the LWP::UserAgent generation method and sets the SSL option to verify the certificate with the bundled certificate. This accomplished by this excerpt:

around _ua => sub {
    my $orig = shift;
    my $self = shift;
 
    my $ua_was_generated = !$self->{_ua};
 
    # Get the standard generated UA
    my $ua = $self->$orig(@_);
 
    if ($ua_was_generated) {
        # Add our SSL options to the UA
        $ua->ssl_opts(SSL_ca_file => File::ShareDir::dist_file('Test-Reporter-Transport-Metabase-CPANTesters', 'metabase.cpantesters.org.crt'));
    }
 
    return $ua;
};

If you are interested in using the module, you can download the tarball and run the commands outlined in INSTALL and be sure to change your CPAN Reporter configuration as noted in README to actually use the new module. After you install it, you can simply set your CPAN Reporter configuration file to have:

transport = Metabase::CPANTesters id_file ~/.cpanreporter/metabase_id.json

A possible solution to this situation may be for the Test::Reporter::Transport::Metabase to have an option for SSL parameters like the certificate file and pass that parameter on to Metabase::Client::Simple for it to set in it’s LWP::UserAgent instance (or metabase.cpantesters.org could have a certificate signed by a CA trusted by Mozilla, though this solution may cost money for the certificate purchase).

I needed to be able to send reports back to NSCA easily from Perl programs (and without needing to go through the send_nsca program that comes with NSCA). I came across Net::Nsca, which mostly works, besides for the fact that I need to change the packet version in the code to 3 (which is not easy to do since it wasn’t made to be changed).

I decided to make my own NSCA client, using Moose and would be hopefully more flexible. A sort example of sending a report in some routine in a server would be:

sub nsca_heart_beat {
    my ($self) = @_;
 
    $self->nsca_client->send_report(
        hostname => $self->hostname,
        service  => 'server',
        message  => 'Running',
        status   => $Net::NSCA::Client::STATUS_OK,
    );
 
    return;
}

This is good and all, but not really a killer feature by any means. What really is a winner here is the Net::NSCA::Client::ServerConfig class that was added in version 0.007. One of the biggest problems with NSCA is that what is sent over the network is not portable. Yes, the data is made to be aligned in network order, but it actually sends a native C structure over the network. The problem is what happens when the server and client happen to compile different structures? This is what ServerConfig is for. It also makes it easy if it any of the constants defined in the NSCA source files were changed when NSCA was built. This client is the only one of the currently three others on the CPAN to support this.

I’ve currently been working on this module in my spare time and coming up is support for encryption methods besides XOR (like AES) as well as complete support for the standard send_nsca.cfg configuration file, plus much more.

Anyhow, in Windows Vista and up the User Account Control feature has a backwards-compatibility feature where for programs that don’t contain manifest files (presumably because they aren’t UAC-aware) Windows will look at certain characteristics of the file to determine if it needs Administrative privileges to run properly. One of the ways it determines this is by file name. The utility that comes with the C tool chain in Strawberry Perl patch.exe triggers this detection mechanism because of the word “patch” in the file name. Because of this it is pretty much impossible to install modules like Math::Pari that make use of the patch.exe program.

A few days ago I saw a new development release of Win32::Exe (0.12_03) was released and saw it supported viewing and modifying of embedded manifests! I decided to use this on the patch.exe file in Strawberry Perl to set the required privilege level to asInvoker (so that UAC is not needed) and it worked! Though you no longer need to do this for the April 2010 and up Strawberry Perl releases, anyone running an older version and not planning to upgrade soon may want to modify their path.exe with the following commands:

C:\> cpan MDOOTSON/Win32-Exe-0.12_03.tar.gz
C:\> perl -MWin32::Exe -e "$e=Win32::Exe->new('c:/strawberry/c/bin/patch.exe'); $m=$e->get_manifest; $m->set_execution_level('asInvoker'); $e->set_manifest($m); $e->write;"