I am getting below error with perl package 5.10.
"inet_pton is not a valid Socket macro"
if (Socket::inet_pton (AF_INET6,$self->{'ip'}) )
{
$log->print("we hit here and ip=$self->{'ip'}");
$self->{'session'} = Net::SNMP->session(-hostname => $self->{'ip'},
-community => $self->{'community'},
-port => $self->{'port'},
-version => 'snmpv2c');
}
Can you pls let me know the root cause ?
Socket uses an autoloader. That's the message it produces when you try to call a sub that doesn't exist.
$ perl -MSocket -wE'my $x = Socket::some_name()'
some_name is not a valid Socket macro at -e line 1
In other words, the error message is synonymous with
Undefined subroutine &Socket::inet_pton called
You must have a version of Socket that predates the addition of the module's support for inet_pton. Therefore, the fix is simply to upgrade that module.
Your Perl is too old. As far as I can tell, inet_pton support wasn't added until 5.12. Installing a newer version of Socket from CPAN may help, but I wouldn't bet on it. Perl 5.10 came out in 2007, and the IPv6 support back then was much worse than it is today.
Related
My Perl script sends some information to a remote server.
Below is a portion of the code
#!/var/hvmail/libexec/perl
use strict;
use HTTP::Request::Common qw(POST);
use LWP::UserAgent;
use constant HANDLER_URL => "https://www.website.com/handler.php";
$ENV{HTTPS_DEBUG} = 1;
my $ua = LWP::UserAgent->new;
# Some DB stuff, not applicable
my $row; # This is a DB row ($sth->fetchrow_hashref())
my $req = POST ''.HANDLER_URL, [ %$row ];
my $res = $ua->request($req);
$res->is_success is false with $res->status_line being
500 SSL negotiation failed
We are running CentOS 6.4, Perl 5.10.1, OpenSSL 1.0.1e-fips.
Update
Here's the full output:
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read server hello A
SSL_connect:before/connect initialization
SSL_connect:SSLv2 write client hello A
SSL_connect:failed in SSLv2 read server hello A
Error: [ 500 SSL negotiation failed: ]
Requested Command Output
Can't locate Net/SSLeay.pm
Can't locate LWP/Protocol/https.pm
You seem to be relying on Crypt::SSLeay. You shouldn't. It's outdated and incomplete.
Install the latest LWP::Protocol::https which will upgrade your LWP and install the preferred SSL/TLS stack consisting of the IO::Socket::SSL and Net::SSLeay.
A web search shows there are CentOS6 repositories with RPM packages for LWP::Protocol::https.
The server has disabled SSLv3 support which means the negotiation fails.
Once you install the package, if you are still seeing the same error, make sure your script is not forcing the use of Crypt::SSLeay. That is, make sure none of the following appears anywhere in your script:
use Net::HTTPS;
$Net::HTTPS::SSL_SOCKET_CLASS = 'Net::SSL';
or
local $ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS} = 'Net::SSL';
or
use Net::SSL;
If you are still running into problems, make sure there is no PERL_NET_HTTPS_SSL_SOCKET_CLASS environment variable in the script's run time environment.
Also, try
$ /var/hvmail/libexec/perl -MNet::SSLeay -le 'print $Net::SSLeay::VERSION'
and
$ /var/hvmail/libexec/perl -MLWP::Protocol::https -le 'print $LWP::Protocol::https::VERSION`'
and report the output.
I suspect the issue is that the new packages were installed for the system's perl whereas it seems you may have a separate perl.
If that is the case, you should install each package individually using /var/hvmail/libexec/perl. For example:
$ curl -O https://cpan.metacpan.org/authors/id/M/MI/MIYAGAWA/App-cpanminus-1.7043.tar.gz
$ tar xvf App-cpanminus-1.7043.tar.gz
$ cd App-cpanminus-1.7043
$ /var/hvmail/libexec/perl Makefile.PL
$ make install
Figure out where cpanm was installed. I am hoping /var/hvmail/libexec.
$ /var/hvmail/libexec/cpanm LWP::Protocol::https
See also Updating all outdated Perl modules, but that may be risky on a production. Still, installing App::cpanoutdated, and seeing how outdated your Perl modules are might be useful
Now, keep in mind that tinkering with a production install like this is risky. Make sure you have a way to undo changes in case something goes wrong.
Finally, note that OpenSSL 1.0.1 versions are no longer supported:
With regards to current and future releases the OpenSSL project has adopted the following policy:
Version 1.1.0 will be supported until 2018-08-31.
Version 1.0.2 will be supported until 2019-12-31 (LTS).
Version 1.0.1 is no longer supported.
Version 1.0.0 is no longer supported.
Version 0.9.8 is no longer supported.
There is no need for ''.HANDLER_URL. It looks ugly, and HANDLER_URL is fine
You don't explain what is in $row or what the POST call requires, but it looks like this
my $req = POST ''.HANDLER_URL, [ %$row ];
my $res = $ua->request($req);
should be
my $res = $ua->post(HANDLER_URL, $row);
I'm trying to publish a module, and am running into a lot of weird errors, the latest of which is as follows:
C:\Shared\John\Perl\unifdef+.0.5.1>build disttest
Creating Makefile.PL
Invalid version format (non-numeric data) at C:/perl/lib/Module/Build/Compat.pm
line 134.
The code at the specified line is:
if ( my $minimum_perl = $requires->{perl} ) {
my $min_ver = version->new($minimum_perl)->numify;
print {$fh} "require $min_ver;\n";
}
so it looks like $minimum_perl is corrupted. I do have the line:
require 5.10.0;
In the code, but that should be OK according to the documentation I've read.
I tried upgrading various modules, and finally I tried a cpan upgrade, and upgraded my entire cpan, but I'm still getting the error. Can anyone tell me what I'm doing wrong? I am running perl 5.24.1
Ok, figured it out (sort of). I'm posting an answer, as I assume others will run into the same problem, and hopefully this will help them. My Build.PL script was a cut/paste/modify from an example on the web. I had the following:
use 5.010000; # NOT 5.8.8 - needed by CPAN testers
use Module::Build;
my $builder = Module::Build->new( module_name => 'code::unifdef+'
, license => 'perl'
, requires => { perl => '>= 5.10.0' } #hmm, this doesn't work...
, dist_version => '0.005.001'
, dist_author => 'John Ulvr <perldev#ulvr.com>'
, dist_abstract => 'processes conditional parts of makefiles, c/c++ and kconfig files'
, create_readme => 0
, create_makefile_pl => 'traditional'
);
$builder->create_build_script; #generate Build
The requires line was causing the problem. I'm not sure why though, as I've seen other similar examples on the web of the requires clause, so either everyone is wrong, or there's some sort of bug in in Compat.pm. Removing the requires line fixes the problem (I have requires in the .pl file itself, so it should catch out-of-date issues).
I am trying to use Perl and Net::SNMP to query a device that has multiple configured views/contexts (a Cisco ACE 4710, for example). The equivalent snmpwalk command is:
snmpwalk -c public#CONTEXT_NAME -v 2c 1.2.3.4 '.1.3.6.1.4.1.9.9.480.1.1.2'
I can enumerate the various contexts/views with SNMP-VIEW-BASED-ACM-MIB, e.g.:
my $vacmContextName = '.1.3.6.1.6.3.16.1.1.1.1';
my ($session, $error) = Net::SNMP->session(-hostname => '1.2.3.4', -community => 'public');
my %contexts = %{ $snmp->get_entries(-columns => [ $vacmContextName ]) };
...but am having trouble now reading any further OIDs from each specific context, e.g.:
my $ciscoL4L7ResourceLimitTable = '.1.3.6.1.4.1.9.9.480.1.1.2';
my ($session, $error) = Net::SNMP->session(-hostname => '1.2.3.4', -community => 'public#CONTEXT_NAME');
my %stats = %{ $snmp->get_entries(-columns => [ $ciscoL4L7ResourceLimitTable ]) }
If I run with -debug => DEBUG_ALL, I see the data being returned in the packet inspection (with recognisable data from that context), but then I get a lot of the following errors:
error: [131] Net::SNMP::Security::Community::process_incoming_msg(): The community name "public#CONTEXT_NAME" was expected, but "public" was found
error: [218] Net::SNMP::MessageProcessing::prepare_data_elements(): The community name "public#CONTEXT_NAME" was expected, but "public" was found
error: [398] Net::SNMP::Dispatcher::_transport_response_received(): The community name "public#CONTEXT_NAME" was expected, but "public" was found
error: [1234] Net::SNMP::__ANON__(): The community name "public#CONTEXT_NAME" was expected, but "public" was found
error: [2363] Net::SNMP::__ANON__(): The community name "public#CONTEXT_NAME" was expected, but "public" was found
...and the resulting contents of %stats is undef.
If I try with -community => 'public', it works, but I only get values from the default context (which doesn't contain everything I need).
If I try with -contextname => 'CONTEXT_NAME', I just get:
error: [2423] Net::SNMP::_context_name(): The contextName argument is only supported in SNMPv3
Is it not possible to do what I need with Net::SNMP?
This is perl, v5.10.1 (*) built for i386-linux-thread-multi
CPAN_FILE D/DT/DTOWN/Net-SNMP-v6.0.1.tar.gz
INST_VERSION v6.0.1
From an email conversation I just had with the package author, Word-of-$DEITY is:
Cisco's "context implementation" is vendor specific and is not standards based. The use of "contexts" is officially defined in the SNMPv3 RFCs (specifications). The Net::SNMP modules tries to follow the RFCs in its implementation. I would have to go back to the RFCs determine if it is legal to respond to an SNMP v1/2c message with a "community" string that is not the same as the one with which the request was made. This is the problem that you are seeing.
You are most likely not going to get Cisco to change their implementation even if it is violating an RFC, so your only recourse is to comment out the code in the Net/SNMP/Security/Community.pm module that is returning an error on the send/receive of differing community strings. I typically do not add modification to the module to work around vendor specific problems.
Rather than comment out the relevant section of the Community.pm (which is used by far more on my server than just this script), I have instead elected to shim/monkey-patch the method in question in my own code, for example:
no warnings 'redefine';
use Net::SNMP::Security::Community;
*Net::SNMP::Security::Community::process_incoming_msg = sub { return 1; };
This way, the failing method is bypassed in favour of just accepting any returned community string.
Filthy dirty on all counts, but acceptable within my controlled environment. Anyone coming across this in the future should make sure that version != 6.0.1 hasn't changed the way this module works, or what the existing subroutine does before attempting the same.
I'm trying to script some interaction between a Linux box and an ESXi host, using the VMware Perl library (which appears to call a SOAP service on the ESXi host).
I am getting an error for which I can't find a solution: Undefined subroutine &LWP::Protocol::https::Socket::can_read called at /usr/local/share/perl5/LWP/Protocol/http.pm line 22
I am currently running Net-HTTP-6.03. I did try with Net-HTTP-6.05 but it makes the web-based calls very slow (and subsequent ones also eventually fail, instead with about 1.2MB of XML as the error message) -- which various forums suggest is only resolvable by reverting to 6.03 (via cpan install GAAS/Net-HTTP-6.03.tar.gz).
The crux of my code is as follows:
use VMware::VIRuntime;
my $context = {
options => ParseOptions(), # result of using GetOpts::Long to parse command-line
session => undef
};
$ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS} = "Net::SSL"; # Suppresses SSL_VERIFY_NONE
if ($context->{options}->{'ignore-ssl-errors'}) {
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; # Ignores certificate errors
}
## next line fails
$context->{session} = Vim::login(
service_url => $context->{options}->{url},
username => $context->{options}->{username},
password => $context->{options}->{password}
);
Is there something else I (can|need to) do to get this working?
I've got it. I needed to reinstall Bundle::LWP from an older version, not just Net-HTTP. Without it, I had LWP v6.05 trying to talk to Net-HTTP v6.03.
Once I realised that LWP == libwww-perl (yes, I'm that new), I found the overall package I needed:
cpan install GAAS/libwww-perl-6.03.tar.gz
Reproduced with LWP 6.05 and Net::HTTP 6.01, which is the cocktail that MacPorts installs at the time of this writing. Upgrading Net::HTTP to 6.06 (current) solved it:
sudo cpan Net::HTTP
I'm having somewhat weird problem with DBD::Informix. If I run a simple script like that:
use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...
It works all right. But if I try to do exactly the same from a test script it fails with the following message:
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
The only difference I see is that test script is quite heavy on module usage; it is based on Test::More and loads a lot of submodules that are to be tested.
Turning on DBI trace does not provide anything useful (for me, at least). Simple script runs along just fine:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms#cms_ol' - no user info
-->> DBD::Informix::dbd_ix_db_check_for_autocommit()
... and the only difference in trace of the problematic script I see is that it just fails:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
<<-- dbd_ix_db_connect (**ERROR-1**)
<<-- DBD::Informix::dbd_ix_db_connect()
I'm running custom Perl 5.8.9 build in Solaris 9, with latest DBI and DBD::Informix versions, against Informix IDS 9.40UC.
Update: If I try to be a smartass and put a block like that at the top of the heavy test script:
use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }
... it prints like this:
Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.
My guess is that DBD::Informix conflicts with some of the modules loaded after the connection is made. But which one? That's the question...
Another update: It appears that the above trick does something unwieldy. I tried to load all the modules explicitly by replacing 'use Module' with 'require Module; Module->import'. Pure Perl modules are OK but whenever XS module using XSLoader appears, Perl goes boom with friendly 'Out of memory' message. And if I move Informix connection below module initialization, it works all right - except DBD::Informix fails with the same -25588 error. Boomer. I'm at loss. :(
Another another update: I tried to run the same script with standard Perl 5.6.1 shipped with Solaris 9, using DBI 1.601 (the latest that would compile with Perl 5.6) and DBD::Informix 2011.0612. Same thing, so it's not custom Perl giving me trouble.
I can also add that the test module in question was prototyped using DBD::SQLite and fully works. It is the final test with DBD::Informix that is failing... As usual. :/
Workaround: following e-mail discussion with Jonathan, a workaround was found: addition of streams-based 'onipcstr' connection to Informix server allowed DBD::Informix to connect. Apparently, some XS modules interfere with default shmem-based connection method, although the culprit is unknown at the moment.
Further discussion
Custom-built Perl is, in my experience, easier than the system Perl. I never modify the system's Perl installation (I don't want to break it) so I always build my own.
You appear to have:
Solaris 9 (SPARC?)
Perl 5.8.9
DBI 1.616
DBD::Informix 2011.0612
ESQL/C (CSDK) 2.81
Informix Dynamic Server 9.40
We don't have the detailed sub-version of ESQL/C and IDS (2.81.UC2, 9.40.UC5, or whatever). There's a hint that you are using a 32-bit version of IDS, so probably everything is 32-bit. You are probably aware that 9.40 is no longer supported by IBM (and, indeed, its successor version 10.00 is also out of support). However, superficially, none of that should matter very much. The failing t91lvarchar.t is not a big issue.
Can you run the connect in working and non-working modes with DBI_TRACE=9 set in the environment.
If the trace for the connect operation is too voluminous to go into an update to the question, we'd better take this off-line to the DBD::Informix support channels (that's me, but by email).
The 'ISAM' error of 22 (Invalid argument) is puzzling. I'm curious about what is in your sqlhosts file for this server - the entry for cms_ol specifically. I'm not sure it will reveal anything, not least because you say the sample ESQL/C below (in the 'First hypothesis' section) works OK, and sometimes the Perl connects and sometimes it does not.
I wonder if there is a name conflict somewhere between functions in the shared libraries? That sort of thing will be hell to track.
First hypothesis
Further information received shows that this was not the crucial distinction.
The difference appears to be:
Works: CONNECT TO 'cms#cms_ol' - no user info
Fails: CONNECT TO 'cms' - no user info
The tricky part to explain is why the second fails, especially as the error goes on to mention cms_ol.
The workaround is to specify the server name in the connect string:
DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
DBI->connect_cached(dbi:Informix:cms, , ****)
The underlying problem is more likely at the ESQL/C level than anything to do with other Perl modules. That is, if you compiled and executed this ESQL/C program, it would fail on cms and work on cms#cms_ol:
int main(int argc, char **argv)
{
$ char *dbs = "cms";
if (argc > 1)
dbs = argv[1];
$ whenever error stop;
$ connect to :dbs;
return 0;
}
You could run it without an explicit database name (or with an explicit 'cms'), and I would expect it to fail. You could run it with 'cms#cms_ol' and I would expect it to pass. The program will say nothing if it passes; it will be obvious when it fails (though the messages will not be beautiful).
There is an outside chance it is something to do with connect_cached; that is a service provided by the DBI module and not by the DBD::Informix module. On the whole though, it is more likely something happening at the ESQL/C level.