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