13399 
0
I have an issue where the status_code() or status_detail() is empty if session fails when used with Perl on Windows. On a Linux machine it runs just fine.
Here is a simple code I used on both Windows and Linux and I use 2 Virtual appliances one with NIOS 7.3.8 (which I have installed the perl module on both Linux and Windows) and one with 7.3.10 so I can force an error when trying to setup a session. The session to 7.3.8 will be succesfull and the session to 7.3.10 should fail.
(x.x.x.x is the ip-adres of the Virtual appliance)
code:
#!/usr/bin/perl
use strict ;
use warnings;
use Carp;
use Cwd;
use Infoblox;
# Determine OS for use read_password
BEGIN {
if ($^O eq "MSWin32") {
require Term::ReadPassword::Win32;
import Term::ReadPassword::Win32 qw(read_password);
} else {
require Term::ReadPassword;
import Term::ReadPassword qw(read_password);
}
}
my $pwd = passwd();
my $session = session("x.x.x.x", "admin", $pwd);
print $session->status_code( )."\n";
sub session {
my ($gm, $username, $pwd ) = @_;
print "Setting up session. One moment please...";
my $session = Infoblox:
ession->new(
"master" => "$gm",
"username" => "$username",
"password" => "$pwd"
);
if ($session->status_code()) {
die("Construct session failed: ",
$session->status_code() . ":" . $session->status_detail());
}
print "Session created successfully\n";
return $session;
}
sub passwd {
our $pwd = read_password("Password: ");
return $pwd;
}
Results:
Windows against Nios 7.3.8 (successful session)
output on screen:
C:\scripts>simple.pl
Password:
Setting up session. One moment please...Session created successfully
0
C:\scripts>
Linux against Nios 7.3.8 (seccessful session)
output on screen:
root@zt--ub01:/opt/scripts# ./simple.pl
Password:
Setting up session. One moment please...Session created successfully
0
root@zt--ub01:/opt/scripts#
Windows against Nios 7.3.10 (fails due to wrong perl module version)
output on screen:
C:\scripts>simple.pl
Password:
Setting up session. One moment please...
C:\scripts>
Linux against Nios 7.3.10 (fails due to wrong perl module version)
output on screen:
root@zt--ub01:/opt/scripts# ./simple.pl
Password:
Construct session failed: 1009:The version of perl module [7.3.8-340539] doesn't match the server version [7.3.10-345050]. Please upgrade your Infoblox perl module package at ./simple.pl line 33.
Setting up session. One moment please...root@zt--ub01:/opt/scripts#
As you can see there is no output on status_code() on Windows when the session fails so the "die" in Perl won't work either and hense you can't build any proper fail safe for it or a proper Log function for troubleshooting.
13400 0
I would also double check which libraries are being loaded on the 2 client systems to make sure that you are getting a version mismatch.
you can do that with an undocumented creation of any object:
my $host = Infoblox:
NS::Host->new ("name" => "name");
my $CLIENT_REV = $host->{__version} ;
You might also try just dumping $session to see what it looks like, instead of testing for $session->status_code().
Something else (e.g. LWP errors) may have caused $session to fail to create.
Note that SSL errors are not reported by the Perl API when debugging
SSL connection issues (1006 'can't connect' errors). Infoblox
recommends that you add either
use IO::Socket::SSL qw(debug3);
or
use Net::SSLeay;
$Net::SSLeay::trace = 3;
to your Perl program before the "use Infoblox; line" to receive more
complete debugging information.
13400 0
13400 0
Ok, I have done some more investigation on this issue and used the perl debug mode (perl -d)
It seems that it won't setup a session because Crypt:SLeay is not installed.
DB<1> n
Can't locate Crypt/SSLeay.pm in @INC (you may need to install the Crypt:SLeay
module) (@INC contains: modules/ D:/perl/site/lib D:/perl/lib .) at D:/perl/site
/lib/Infoblox/Agent.pm line 75.
at D:/perl/site/lib/Infoblox/Agent.pm line 75.
Infoblox::Agent::new("Infoblox::Agent", "timeout", undef, "keep_alive",
1, "blox_session", Infoblox:ession=HASH(0x2996b40), "blox_agent", LWP::UserAge
nt=HASH(0x17228a00), ...) called at D:/perl/site/lib/Infoblox/Session.pm line 44
2
Infoblox:ession::create_ibap_server(Infoblox:ession=HASH(0x2996b40),
LWP::UserAgent=HASH(0x17228a00)) called at D:/perl/site/lib/Infoblox/Session.pm
line 117
When I try to install Crypt:SLeay I get the following message:
*** THIS IS NOT AN ERROR, JUST A MESSAGE FOR YOUR INFORMATION ***
Do you really need Crypt:SLeay?
Starting with version 6.02 of LWP, https support was unbundled into
LWP:
rotocol::https. This module specifies as one of its prerequisites
IO:ocket:SL which is automatically used by LWP::UserAgent unless
this preference is overridden separately. IO:ocket:SL is a more
complete implementation, and, crucially, it allows hostname
verification. Crypt:SLeay does not support this. At this point,
Crypt:SLeay is maintained to support existing software that already
depends on it.
However, it is possible that your software does not really depend on
Crypt:SLeay, only on the ability of LWP::UserAgent class to
communicate with sites over SSL/TLS.
If are using version LWP 6.02 or later, and therefore have installed
LWP:rotocol::https and its dependencies, and do not explicitly use
Net:SL before loading LWP::UserAgent, or override the default socket
class, you are probably using IO:ocket:SL and do not really need
Crypt:SLeay.
Before installing Crypt:SLeay, you may want to try specifying a
dependency on LWP:rotocol::https.
Failed to build and link a simple executable using OpenSSL
So it seems that it is missing Crypt:SLeay but I don't need to install it as I am using LWP 6.08 but it doesn't create a session and it doesn't show any message of it.
Why ?
13400 0
@StefanvanH wrote:
Ok, I have done some more investigation on this issue and used the perl debug mode (perl -d)
It seems that it won't setup a session because Crypt:
<snip>
So it seems that it is missing Crypt:
Why ?
It is documented that Crypt:SLeay is a required component and this is needed so that the secure connection to NIOS can be built. Error output is function of PERL and some installations may behave differently from others. This also depends on any error checking that you have built into your script as by default, error messages are pretty sparse.
Regards,
Tony
