Hi Aaron, You're right, RPC-XML wasn't installed, although perl-libwww-perl is installed and updated.
Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get errors when I run Makefile about various missing prerequisites on a clean CentOS install.) Thanks, Mike On Tue, Jan 31, 2012 at 16:49, Aaron Coburn <acob...@amherst.edu> wrote: > Oh. It looks like RPC-XML is not installed. > > You can verify that by using this command: > > perl -MRPC::XML -e "print 'have a nice day'" > > If you get errors, the module isn't installed. If the script seems > friendly, then the module is installed. > > If the module is not installed, download it from here: > http://search.cpan.org/dist/RPC-XML/ > > unpack it and install it like so: > > perl Makefile.PL > make && make test > sudo make install > > Then try the command again that I listed above. > > > > On Jan 31, 2012, at 4:42 PM, Mike Haudenschild wrote: > > > Hi Aaron, > > > > I get the following errors running install_perl_libs from trunk, on > CentOS > > 5.7 fully updated: > > > > *No package perl-CPAN available.* > > *WARNING: unexpected output returned while installing Linux package: > > 'perl-CPAN'* > > *this has happened since my first install, but doesn't seem to be a > problem > > since cpan is already installed in CentOS base > > > > *No package perl-RPC-XML available.* > > *WARNING: unexpected output returned while installing Linux package: > > 'perl-RPC-XML'* > > *this has also happened since my first install, but I've never been able > to > > resolve this. I thought perhaps the CPAN commands issued at the end of > the > > install script installed RPC::XML from CPAN...? > > > > All of the PERL module installs throw: > > *Unknown command 'notest'. Type ? for help.* > > > > Two PERL modules fail to install: > > > > *Attempting to install Perl module using CPAN: 'Object::InsideOut'* > > *Unknown command 'notest'. Type ? for help.* > > *checking if Object::InsideOut Perl module is installed...* > > *Perl module Object::InsideOut appears to be installed but the version > > could not be determined* > > *command: perl -e "eval \"use Object::InsideOut\"; print > > \$Object::InsideOut::VERSION" 2>&1* > > *output:* > > *ERROR: failed to install Perl module: 'Object::InsideOut'* > > > > > > *Attempting to install Perl module using CPAN: 'RPC::XML'* > > *Unknown command 'notest'. Type ? for help.* > > *checking if RPC::XML Perl module is installed...* > > *Perl module RPC::XML appears to be installed but the version could not > be > > determined* > > *command: perl -e "eval \"use RPC::XML\"; print \$RPC::XML::VERSION" > 2>&1* > > *output:* > > *ERROR: failed to install Perl module: 'RPC::XML'* > > > > 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. > >> > >
