You shouldn't have to install anything manually. It looks like there
are some problems with the current install_perl_libs.pl script. There
is a CPAN "notest" option which I added to make the script run a lot
faster. Apparently this option isn't always available. Try editing
install_perl_libs.pl and then run it again. Swap the comment from the
"install" line to the "notest" line, change:
eval { CPAN::Shell->notest("install", $perl_module) };
#eval { CPAN::Shell->install($perl_module) };
-to-
#eval { CPAN::Shell->notest("install", $perl_module) };
eval { CPAN::Shell->install($perl_module) };
Also, was epel successfully installed? Run 'yum repolist'. Do you
see epel listed? If not, check the install_perl_libs.pl output for
errors when it tries to install it.
-Andy
On Tue, Jan 31, 2012 at 6:07 PM, Mike Haudenschild <m...@longsight.com> wrote:
> Here's the output:
>
> @@@@@
> XML::LibXML not found
>
> You may ignore the warnings about XML::LibXML not being present, if
> you plan only to use the XML::Parser-based parsing engine. The use
> of XML::LibXML is completely optional.
> @@@@@
>
> WARNING: MIN_PERL_VERSION is not a known parameter.
> WARNING: META_MERGE is not a known parameter.
> WARNING: LICENSE is not a known parameter.
> Warning: prerequisite LWP 5.834 not found. We have 5.805.
> Warning: prerequisite Test::More 0.94 not found. We have 0.62.
> 'LICENSE' is not a known MakeMaker parameter name.
> 'META_MERGE' is not a known MakeMaker parameter name.
> 'MIN_PERL_VERSION' is not a known MakeMaker parameter name.
> Writing Makefile for RPC::XML
>
>
>
> On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild <m...@longsight.com> wrote:
>
>> 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.
>>> >>
>>>
>>>
>>
