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 >>> >> >> >
