Not sure what you mean by "hand install". That should have been installed as a part of perl-libwww-perl. Try:
yum info perl-libwww-perl RPC-XML will require using either cpan or the standard: perl Makefile.PL make && make test make install I would recommend NOT using cpan, since it can create hard-to-debug conflicts with the CentOS libraries, especially if they are installed in the wrong order. There may also be a networking issue involved. Can you access the vcl website correctly from the management node? curl -L https://your website.org If those check out, try accessing the XML-RPC interface directly through a little external perl script (naturally, from the management node). Here's an example:
#!/usr/bin/perl -w use strict; use RPC::XML::Client; use Term::ReadKey; my $VCL_LOCATION = 'https://YOUR WEBSITE?mode=xmlrpccall'; $|++; print "Username: "; chomp(my $username = <>); print "Password: "; ReadMode 2; chomp(my $password = <>); ReadMode 0; print "\n"; my $client = RPC::XML::Client->new($VCL_LOCATION); $client->fault_handler( sub { print "XML-RPC Fault: ", $_[0]->value->{'faultString'}, "\n"; exit; }); $client->error_handler( sub { print "XML-RPC Error: ", $_[0]->value->{'errorString'}, "\n"; exit; }); $client->useragent->default_header('X-User' => $username); $client->useragent->default_header('X-Pass' => $password); $client->useragent->default_header('X-APIVERSION' => 2); print $_->value->{'name'}, "\n" foreach @{$client->send_request(("XMLRPCgetImages"))};
Aaron On Jan 31, 2012, at 3:23 PM, Mike Haudenschild wrote: > Hi Aaron, > > I really appreciate your response -- starting to sweat bullets on this one. > Still seeing the problem. It starts out as: > > |3425|blockrequest| ---- CRITICAL ---- > |3425|blockrequest| 2012-01-31 > 10:45:07|3425|blockrequest|vcld:die_handler(636)|Can't locate object method > "type" via package "RPC::XML::Client::send_request: HTTP server error: > Protocol scheme 'https' is not supported (LWP::Protocol::https not > installed)" (perhaps you forgot to load "RPC::XML::Client::send_request: > HTTP server error: Protocol scheme 'https' is not supported > (LWP::Protocol::https not installed)"?) at /usr/local/vcl/bin/../lib/VCL/ > utils.pm line 9121. > |3425|blockrequest| ( 0) vcld, die_handler (line: 636) > |3425|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) > |3425|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) > |3425|blockrequest| (-3) blockrequest.pm, process (line: 193) > |3425|blockrequest| (-4) vcld, make_new_child (line: 568) > |3425|blockrequest| (-5) vcld, main (line: 448) > > And if I hand-install LWP::Protocol::https, it becomes: > > |5745|blockrequest| ---- CRITICAL ---- > |5745|blockrequest| 2012-01-31 > 11:24:30|5745|blockrequest|vcld:die_handler(636)|Can't locate object method > "type" via package "RPC::XML::Client::send_request: HTTP server error: > Can't connect to urichmond.longsight.com:443 (certificate verify failed)" > (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP server > error: Can't connect to urichmond.longsight.com:443 (certificate verify > failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. > |5745|blockrequest| ( 0) vcld, die_handler (line: 636) > |5745|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) > |5745|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) > |5745|blockrequest| (-3) blockrequest.pm, process (line: 193) > |5745|blockrequest| (-4) vcld, make_new_child (line: 568) > |5745|blockrequest| (-5) vcld, main (line: 448) > > I have been using the install_perl_libs.pl from the 2.2.1 distro -- I will > bring up a clean OS and try this. I've been using CentOS 5.7 -- is 5.x > still the most appropriate version? > > Thanks! > Mike > -- > *Mike Haudenschild* > Education Systems Manager > Longsight Group > (740) 599-5005 x809 > m...@longsight.com > www.longsight.com > > > > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aaron_pee...@ncsu.edu> wrote: > >> Hi Mike, >> >> Apologies for not responding on this. >> >> Are you still seeing this issue with your block allocations? >> >> If so you could try to use the latest install_perl_libs.pl script >> >> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl >> >> Aaron >> >> On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild <m...@longsight.com> >> wrote: >>> Dev team, >>> >>> I would very much appreciate guidance on whether I should try defining >> (or >>> bypassing) the SSL cert variables in the PERL scripts, or if I should/can >>> downgrade the applicable PERL modules to older known-working versions to >>> workaround this issue altogether. >>> >>> The log was telling me that LWP::Protocol::https was required, and it's >> not >>> installed by the install_perl_libs script (because LWP::Protocol::https >> was >>> recently split out from libwww-perl?). Once installed, however, I get >>> static as shown in the logs below. >>> >>> I'm dead in the water with block allocations. Thanks very much for any >>> help. >>> >>> Regards, >>> Mike >>> >>> >>> On Tue, Jan 24, 2012 at 21:00, Mike Haudenschild <m...@longsight.com> >> wrote: >>> >>>> Good evening, >>>> >>>> I apologize for the numerous emails, but as I continue working through >>>> this something new popped up: >>>> >>>> I managed to get LWP::Protocol::https to install by first updating >>>> Net::SSLLeay with CPAN. >>>> >>>> However, when making a block allocation I now get this in the log: >>>> >>>> |4978|blockrequest| ---- CRITICAL ---- >>>> |4978|blockrequest| 2012-01-24 20 >> :53:45|4978|blockrequest|vcld:die_handler(636)|Can't >>>> locate object method "type" via package "RPC::XML::Client::send_request: >>>> HTTP server error:* Can't connect to vclserver:443< >> http://urichmond.longsight.com:443>(certificate verify failed) >>>> *" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP >>>> server error: Can't connect to server.domain.com:443 (certificate >> verify >>>> failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. >>>> |4978|blockrequest| ( 0) vcld, die_handler (line: 636) >>>> |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) >>>> |4978|blockrequest| (-2) blockrequest.pm, process_block_time (line: >> 373) >>>> |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) >>>> |4978|blockrequest| (-4) vcld, make_new_child (line: 568) >>>> |4978|blockrequest| (-5) vcld, main (line: 448) >>>> >>>> 2012-01-24 20 >> :53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest >>>> destructor called, address: f7be070 >>>> 2012-01-24 20:53:45|4978|blockrequest|State.pm:DESTROY(848)|number of >>>> database handles state process created: 1 >>>> 2012-01-24 20:53:45|4138|vcld:REAPER(718)|VCL process exited for >>>> reservation <unknown>, PID: 4978, signal: CHLD >>>> >>>> My limited understanding of PERL is at play here, but from my research >> it >>>> seems that updated versions of LWP::UserAgent do strict SSL certificate >>>> checking. (We do have a CA-issued SSL cert installed for the VCL Web >> front >>>> end.) >>>> >>>> >>>> >> http://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates >>>> >>>> I'd very much appreciate any feedback from experts on the list. >>>> >>>> Many thanks, >>>> Mike >>>> >>>> >>>> On Tue, Jan 24, 2012 at 20:12, Mike Haudenschild <m...@longsight.com >>> wrote: >>>> >>>>> I've been looking into this further, and I've found what appears to be >> a >>>>> missing PERL module (LWP::Protocol::https). I attempted to install it >>>>> manually with CPAN, but I get two test errors. I've attached the CPAN >>>>> error message immediately below, and the section of vcld.log from the >>>>> moment I save the block allocation. >>>>> >>>>> Thanks to all, >>>>> Mike >>>>> >>>>> ------ >>>>> >>>>> t/apache....# Failed test 1 in t/apache.t at line 12 >>>>> # t/apache.t line 12 is: ok($res->is_success); >>>>> # Failed test 2 in t/apache.t at line 13 >>>>> # t/apache.t line 13 is: ok($res->content =~ /Apache Software >>>>> Foundation/); >>>>> t/apache....FAILED tests 1-2 >>>>> Failed 2/2 tests, 0.00% okay >>>>> Failed Test Stat Wstat Total Fail Failed List of Failed >>>>> >>>>> >> ------------------------------------------------------------------------------- >>>>> t/apache.t 2 2 100.00% 1-2 >>>>> Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% okay. >>>>> make: *** [test_dynamic] Error 255 >>>>> /usr/bin/make test -- NOT OK >>>>> Running make install >>>>> make test had returned bad status, won't install without force >>>>> >>>>> ------ >>>>> >>>>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >> process(166)|owner >>>>> email: root@localhost >>>>> Use of uninitialized value in concatenation (.) or string at >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167 (#1) >>>>> (W uninitialized) An undefined value was used as if it were already >>>>> defined. It was interpreted as a "" or a 0, but maybe it was a >>>>> mistake. >>>>> To suppress this warning assign a defined value to your variables. >>>>> >>>>> To help you figure out what was undefined, perl tells you what >>>>> operation >>>>> you used the undefined value in. Note, however, that perl >> optimizes >>>>> your >>>>> program and the operation displayed in the warning may not >> necessarily >>>>> appear literally in your program. For example, "that $foo" is >>>>> usually optimized into "that " . $foo, and the warning will refer >> to >>>>> the concatenation (.) operator, even though there is no . in your >>>>> program. >>>>> >>>>> >>>>> |3518|blockrequest| ---- WARNING ---- >>>>> |3518|blockrequest| 2012-01-24 19 >> :40:35|3518|blockrequest|vcld:warning_handler(610)|Use >>>>> of uninitialized value in concatenation (.) or string at >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167. >>>>> |3518|blockrequest| ( 0) vcld, warning_handler (line: 610) >>>>> |3518|blockrequest| (-1) blockrequest.pm, process (line: 167) >>>>> |3518|blockrequest| (-2) vcld, make_new_child (line: 568) >>>>> |3518|blockrequest| (-3) vcld, main (line: 448) >>>>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >> process(167)|help >>>>> address: >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >> process(172)|updated >>>>> process flag on blocktime_id= 4 >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >> process(192)|processing >>>>> blocktime_id= 4 pass 1 >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm: >> xmlrpc_call(9105)|argument_string= >>>>> XMLRPCprocessBlockTime 4 1 >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm:mail(1268)|SUCCESS -- >>>>> Sending mail To: 0, PROBLEM -- vcld:die_handler(636)|test >>>>> >>>>> |3518|blockrequest| ---- CRITICAL ---- >>>>> |3518|blockrequest| 2012-01-24 19 >> :40:35|3518|blockrequest|vcld:die_handler(636)|Can't >>>>> locate object method "type" via package >> "RPC::XML::Client::send_request: >>>>> HTTP server error: Protocol scheme 'https' is not supported >>>>> (LWP::Protocol::https not installed)" (perhaps you forgot to load >>>>> "RPC::XML::Client::send_request: HTTP server error: Protocol scheme >> 'https' >>>>> is not supported (LWP::Protocol::https not installed)"?) at >>>>> /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. >>>>> |3518|blockrequest| ( 0) vcld, die_handler (line: 636) >>>>> |3518|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) >>>>> |3518|blockrequest| (-2) blockrequest.pm, process_block_time (line: >> 373) >>>>> |3518|blockrequest| (-3) blockrequest.pm, process (line: 193) >>>>> |3518|blockrequest| (-4) vcld, make_new_child (line: 568) >>>>> |3518|blockrequest| (-5) vcld, main (line: 448) >>>>> >>>>> 2012-01-24 19 >> :40:35|3518|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest >>>>> destructor called, address: 96b7c1c >>>>> 2012-01-24 19:40:35|3518|blockrequest|State.pm:DESTROY(848)|number of >>>>> database handles state process created: 1 >>>>> 2012-01-24 19:40:35|3459|vcld:REAPER(718)|VCL process exited for >>>>> reservation <unknown>, PID: 3518, signal: CHLD >>>>> >>>>> >>>>> >>>>> On Tue, Jan 24, 2012 at 12:05, Mike Haudenschild <m...@longsight.com >>> wrote: >>>>> >>>>>> Hello, VCL dev -- >>>>>> >>>>>> I've seen three instances of "relaim" errors on my VCL instance today >> -- >>>>>> machines that vcld couldn't seem to reach, although they appeared >> running >>>>>> on the ESXi console. >>>>>> >>>>>> It started when I began creating block allocations (which did not >> appear >>>>>> to work). In both cases there seemed to be text in the log regarding >>>>>> incorrect SQL syntax. >>>>>> >>>>>> After the errors, the affected machines showed as "failed" in the VCL >>>>>> front end, but eventually reloaded and appear to be working fine. >>>>>> >>>>>> Regular, individual reservations appear to be working fine. I've >>>>>> attached both snippets of log and would appreciate any feedback. >>>>>> >>>>>> Many thanks, >>>>>> Mike >>>>>> >>>>> >>>>> >>>> >> >> >> >> -- >> Aaron Peeler >> Program Manager >> Virtual Computing Lab >> NC State University >> >> All electronic mail messages in connection with State business which >> are sent to or received by this account are subject to the NC Public >> Records Law and may be disclosed to third parties. >>
