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

Reply via email to