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

Reply via email to