You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Mike Haudenschild <mi...@longsight.com> on 2012/02/01 00:07:17 UTC
Re: VCL block alloc, PERL module issue update
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 <mi...@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 <ac...@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
>> > mike@longsight.com
>> > www.longsight.com
>> >
>> >
>> >
>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aa...@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 <mike@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 <mi...@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 <mike@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 <
>> mike@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.
>> >>
>>
>>
>
Re: VCL block alloc, PERL module issue update
Posted by Mike Haudenschild <mi...@longsight.com>.
Hi Aaron,
I hadn't noticed this specifically (was on CentOS 5.7), but I was hunting
specifically for RPC-XML issues so I might've missed it. I can run another
test install on a clean setup later this week with the updated
install_perl_libs.pl.
Mike
On Fri, Feb 17, 2012 at 09:06, Aaron Peeler <aa...@ncsu.edu> wrote:
> Hi Mike,
>
> When you ran the latest install_perl_libs.pl.
>
> Did you see any errors in the CPAN section - should be toward the end
> of the output.
> That had:
> cpan tar: Options `-[0-7][lmh]' not supported by *this* tar
>
> I'm seeing an error related to config option for cpan that the
> verbosity level is set wrong on different linux OS versions. It's not
> consistent, so just checking to see if you had seen this.
>
> Thanks,
> Aaron
>
>
> On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild <mi...@longsight.com>
> wrote:
> > Hi Andy,
> >
> > I pulled down the updated install_perl_libs.pl and used alongside the
> 2.2.1
> > management node release. I did notice that libwww was installed to
> satisfy
> > dependencies for perl-xml-simple. I didn't do any other tweaking -- just
> > ran the script and otherwise followed the "normal" management node
> install
> > procedure.
> >
> > A block allocation didn't work, however:
> >
> > |3394|blockrequest| ---- CRITICAL ----
> > |3394|blockrequest| 2012-02-06
> > 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object
> method
> > "type" via package "RPC::XML::Client::send_request: HTTP server error:
> you
> > need" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP
> > server error: you need"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line
> > 9121.
> > |3394|blockrequest| ( 0) vcld, die_handler (line: 636)
> > |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
> > |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
> > |3394|blockrequest| (-3) blockrequest.pm, process (line: 193)
> > |3394|blockrequest| (-4) vcld, make_new_child (line: 568)
> > |3394|blockrequest| (-5) vcld, main (line: 448)
> >
> >
> > On Mon, Feb 6, 2012 at 12:23, Andy Kurth <an...@ncsu.edu> wrote:
> >
> >> I updated install_perl_libs.pl in the repository:
> >>
> >>
> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
> >>
> >> You should now be able to run it without having to perform any
> >> additional steps. Please give it a try.
> >>
> >> Thanks,
> >> Andy
> >>
> >> On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <mi...@longsight.com>
> >> wrote:
> >> > All,
> >> >
> >> > I've managed to get around the CRITICAL error I was seeing in the vcld
> >> log
> >> > during block allocations. perl-libwww-perl wasn't installed. *sigh*
> >> > Installing that prior to running install_perl_libs.pl solved the
> >> problem
> >> > (should that be added to the install_perl_libs script?). I noticed
> that
> >> > there are two listings of PERL-related software required for the
> >> management
> >> > node:
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
> >> >
> >> > and
> >> >
> >> > https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
> >> >
> >> > We might want to consolidate those. I was running from the install
> docs
> >> > and didn't even think to check that perl-libwww-perl was installed.
> >> >
> >> > Prior to this, I'd developed a manual workaround, installing RPC-XML
> 0.71
> >> > (which is NOT the most recent version) using the make method from the
> >> CPAN
> >> > archive.
> >> >
> >> > Note that I'm on CentOS 5.7, clean install and fully updated prior to
> >> > install VCL management node. There is no package perl-XML-RPC (called
> >> from
> >> > the script) available from the repos (with EPEL enabled),
> >> > and perl-libwww-perl wasn't installed by default.
> >> >
> >> > Here's the process I used...
> >> >
> >> > 1. Used the 2.2.1 release install_perl_libs.pl script
> >> > 2. Commented out the line that tells install_perl_libs.pl to
> retrieve
> >> > RPC::XML from CPAN (line 285)
> >> > 3. Ran install_perl_libs.pl
> >> > 4. Installed RPC-XML 0.71 from CPAN
> >> > 5. Completed VCL management node install steps from the
> documentation
> >> >
> >> > I went with the lowest-versions of the various dependencies needed by
> >> > RPC-XML 0.71, which is obviously not a best-practice... I'd
> appreciate
> >> any
> >> > feedback from the list on whether that may have unintended
> >> consequences...
> >> >
> >> > Here's the dependency tree with links:
> >> >
> >> > - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
> >> > - libwww-perl (LWP) 5.801 (
> >> > https://metacpan.org/release/GAAS/libwww-perl-5.801)
> >> > - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ...
> note
> >> > that some tests FAILED
> >> > - HTML-Parser 3.33 (
> >> > https://metacpan.org/release/GAAS/HTML-Parser-3.33)
> >> > - HTML-Tagest 3.02 (
> >> > https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
> >> > - XML-Parser 2.31 (
> >> > https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
> >> >
> >> > Having the most recent perl-libwww-perl from CPAN yielded an install
> that
> >> > didn't include LWP::Protocol::https (and the script is trying to make
> an
> >> > HTTPS connection). Installing LWP-Protocol-https doesn't solve the
> >> problem
> >> > because of stricter SSL certification requirements and hostname
> >> > verification (
> >> >
> >>
> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
> >> > ).
> >> >
> >> > Many thanks,
> >> > Mike
> >> >
> >> >
> >> > On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
> >> >
> >> >> 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 <
> mike@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 <
> mike@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 <ac...@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
> >> >> >>> > mike@longsight.com
> >> >> >>> > www.longsight.com
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <
> >> aaron_peeler@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.plscript
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>>
> >> >>
> >>
> 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 <
> >> >> mike@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 <
> >> >> mike@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 <
> >> >> mike@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 <
> >> >> >>> mike@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.
> >> >> >>> >>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >>
> >>
>
>
>
> --
> 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.
>
Re: VCL block alloc, PERL module issue update
Posted by Andy Kurth <an...@ncsu.edu>.
I believe I fixed this in the commit on 2/6. There are a bunch of
CPAN options which get configured in a hash in the configure_cpan
subroutine. These options need to be configured so that CPAN module
installs are non-interactive. I included all the options I could find
in this hash to prevent CPAN from asking any questions. One of the
options is "tar_verbosity". It had previously been set to 0. It
seems as though CPAN takes this parameter and adds "-0" to the tar
arguments. I changed it to a blank string and it seems to have solved
the problem.
-Andy
On Fri, Feb 17, 2012 at 9:06 AM, Aaron Peeler <aa...@ncsu.edu> wrote:
> Hi Mike,
>
> When you ran the latest install_perl_libs.pl.
>
> Did you see any errors in the CPAN section - should be toward the end
> of the output.
> That had:
> cpan tar: Options `-[0-7][lmh]' not supported by *this* tar
>
> I'm seeing an error related to config option for cpan that the
> verbosity level is set wrong on different linux OS versions. It's not
> consistent, so just checking to see if you had seen this.
>
> Thanks,
> Aaron
>
>
> On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild <mi...@longsight.com> wrote:
>> Hi Andy,
>>
>> I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1
>> management node release. I did notice that libwww was installed to satisfy
>> dependencies for perl-xml-simple. I didn't do any other tweaking -- just
>> ran the script and otherwise followed the "normal" management node install
>> procedure.
>>
>> A block allocation didn't work, however:
>>
>> |3394|blockrequest| ---- CRITICAL ----
>> |3394|blockrequest| 2012-02-06
>> 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method
>> "type" via package "RPC::XML::Client::send_request: HTTP server error: you
>> need" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP
>> server error: you need"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line
>> 9121.
>> |3394|blockrequest| ( 0) vcld, die_handler (line: 636)
>> |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
>> |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
>> |3394|blockrequest| (-3) blockrequest.pm, process (line: 193)
>> |3394|blockrequest| (-4) vcld, make_new_child (line: 568)
>> |3394|blockrequest| (-5) vcld, main (line: 448)
>>
>>
>> On Mon, Feb 6, 2012 at 12:23, Andy Kurth <an...@ncsu.edu> wrote:
>>
>>> I updated install_perl_libs.pl in the repository:
>>>
>>> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
>>>
>>> You should now be able to run it without having to perform any
>>> additional steps. Please give it a try.
>>>
>>> Thanks,
>>> Andy
>>>
>>> On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <mi...@longsight.com>
>>> wrote:
>>> > All,
>>> >
>>> > I've managed to get around the CRITICAL error I was seeing in the vcld
>>> log
>>> > during block allocations. perl-libwww-perl wasn't installed. *sigh*
>>> > Installing that prior to running install_perl_libs.pl solved the
>>> problem
>>> > (should that be added to the install_perl_libs script?). I noticed that
>>> > there are two listings of PERL-related software required for the
>>> management
>>> > node:
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
>>> >
>>> > and
>>> >
>>> > https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
>>> >
>>> > We might want to consolidate those. I was running from the install docs
>>> > and didn't even think to check that perl-libwww-perl was installed.
>>> >
>>> > Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
>>> > (which is NOT the most recent version) using the make method from the
>>> CPAN
>>> > archive.
>>> >
>>> > Note that I'm on CentOS 5.7, clean install and fully updated prior to
>>> > install VCL management node. There is no package perl-XML-RPC (called
>>> from
>>> > the script) available from the repos (with EPEL enabled),
>>> > and perl-libwww-perl wasn't installed by default.
>>> >
>>> > Here's the process I used...
>>> >
>>> > 1. Used the 2.2.1 release install_perl_libs.pl script
>>> > 2. Commented out the line that tells install_perl_libs.pl to retrieve
>>> > RPC::XML from CPAN (line 285)
>>> > 3. Ran install_perl_libs.pl
>>> > 4. Installed RPC-XML 0.71 from CPAN
>>> > 5. Completed VCL management node install steps from the documentation
>>> >
>>> > I went with the lowest-versions of the various dependencies needed by
>>> > RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate
>>> any
>>> > feedback from the list on whether that may have unintended
>>> consequences...
>>> >
>>> > Here's the dependency tree with links:
>>> >
>>> > - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
>>> > - libwww-perl (LWP) 5.801 (
>>> > https://metacpan.org/release/GAAS/libwww-perl-5.801)
>>> > - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
>>> > that some tests FAILED
>>> > - HTML-Parser 3.33 (
>>> > https://metacpan.org/release/GAAS/HTML-Parser-3.33)
>>> > - HTML-Tagest 3.02 (
>>> > https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
>>> > - XML-Parser 2.31 (
>>> > https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
>>> >
>>> > Having the most recent perl-libwww-perl from CPAN yielded an install that
>>> > didn't include LWP::Protocol::https (and the script is trying to make an
>>> > HTTPS connection). Installing LWP-Protocol-https doesn't solve the
>>> problem
>>> > because of stricter SSL certification requirements and hostname
>>> > verification (
>>> >
>>> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
>>> > ).
>>> >
>>> > Many thanks,
>>> > Mike
>>> >
>>> >
>>> > On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
>>> >
>>> >> 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 <mi...@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 <mi...@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 <ac...@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
>>> >> >>> > mike@longsight.com
>>> >> >>> > www.longsight.com
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <
>>> aaron_peeler@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.plscript
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>>
>>> >>
>>> 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 <
>>> >> mike@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 <
>>> >> mike@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 <
>>> >> mike@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 <
>>> >> >>> mike@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.
>>> >> >>> >>
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >>
>>>
>
>
>
> --
> 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.
Re: VCL block alloc, PERL module issue update
Posted by Aaron Peeler <aa...@ncsu.edu>.
Hi Mike,
When you ran the latest install_perl_libs.pl.
Did you see any errors in the CPAN section - should be toward the end
of the output.
That had:
cpan tar: Options `-[0-7][lmh]' not supported by *this* tar
I'm seeing an error related to config option for cpan that the
verbosity level is set wrong on different linux OS versions. It's not
consistent, so just checking to see if you had seen this.
Thanks,
Aaron
On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild <mi...@longsight.com> wrote:
> Hi Andy,
>
> I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1
> management node release. I did notice that libwww was installed to satisfy
> dependencies for perl-xml-simple. I didn't do any other tweaking -- just
> ran the script and otherwise followed the "normal" management node install
> procedure.
>
> A block allocation didn't work, however:
>
> |3394|blockrequest| ---- CRITICAL ----
> |3394|blockrequest| 2012-02-06
> 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method
> "type" via package "RPC::XML::Client::send_request: HTTP server error: you
> need" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP
> server error: you need"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line
> 9121.
> |3394|blockrequest| ( 0) vcld, die_handler (line: 636)
> |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
> |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
> |3394|blockrequest| (-3) blockrequest.pm, process (line: 193)
> |3394|blockrequest| (-4) vcld, make_new_child (line: 568)
> |3394|blockrequest| (-5) vcld, main (line: 448)
>
>
> On Mon, Feb 6, 2012 at 12:23, Andy Kurth <an...@ncsu.edu> wrote:
>
>> I updated install_perl_libs.pl in the repository:
>>
>> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
>>
>> You should now be able to run it without having to perform any
>> additional steps. Please give it a try.
>>
>> Thanks,
>> Andy
>>
>> On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <mi...@longsight.com>
>> wrote:
>> > All,
>> >
>> > I've managed to get around the CRITICAL error I was seeing in the vcld
>> log
>> > during block allocations. perl-libwww-perl wasn't installed. *sigh*
>> > Installing that prior to running install_perl_libs.pl solved the
>> problem
>> > (should that be added to the install_perl_libs script?). I noticed that
>> > there are two listings of PERL-related software required for the
>> management
>> > node:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
>> >
>> > and
>> >
>> > https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
>> >
>> > We might want to consolidate those. I was running from the install docs
>> > and didn't even think to check that perl-libwww-perl was installed.
>> >
>> > Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
>> > (which is NOT the most recent version) using the make method from the
>> CPAN
>> > archive.
>> >
>> > Note that I'm on CentOS 5.7, clean install and fully updated prior to
>> > install VCL management node. There is no package perl-XML-RPC (called
>> from
>> > the script) available from the repos (with EPEL enabled),
>> > and perl-libwww-perl wasn't installed by default.
>> >
>> > Here's the process I used...
>> >
>> > 1. Used the 2.2.1 release install_perl_libs.pl script
>> > 2. Commented out the line that tells install_perl_libs.pl to retrieve
>> > RPC::XML from CPAN (line 285)
>> > 3. Ran install_perl_libs.pl
>> > 4. Installed RPC-XML 0.71 from CPAN
>> > 5. Completed VCL management node install steps from the documentation
>> >
>> > I went with the lowest-versions of the various dependencies needed by
>> > RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate
>> any
>> > feedback from the list on whether that may have unintended
>> consequences...
>> >
>> > Here's the dependency tree with links:
>> >
>> > - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
>> > - libwww-perl (LWP) 5.801 (
>> > https://metacpan.org/release/GAAS/libwww-perl-5.801)
>> > - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
>> > that some tests FAILED
>> > - HTML-Parser 3.33 (
>> > https://metacpan.org/release/GAAS/HTML-Parser-3.33)
>> > - HTML-Tagest 3.02 (
>> > https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
>> > - XML-Parser 2.31 (
>> > https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
>> >
>> > Having the most recent perl-libwww-perl from CPAN yielded an install that
>> > didn't include LWP::Protocol::https (and the script is trying to make an
>> > HTTPS connection). Installing LWP-Protocol-https doesn't solve the
>> problem
>> > because of stricter SSL certification requirements and hostname
>> > verification (
>> >
>> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
>> > ).
>> >
>> > Many thanks,
>> > Mike
>> >
>> >
>> > On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
>> >
>> >> 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 <mi...@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 <mi...@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 <ac...@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
>> >> >>> > mike@longsight.com
>> >> >>> > www.longsight.com
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <
>> aaron_peeler@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.plscript
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >>
>> 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 <
>> >> mike@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 <
>> >> mike@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 <
>> >> mike@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 <
>> >> >>> mike@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.
>> >> >>> >>
>> >> >>>
>> >> >>>
>> >> >>
>> >>
>>
--
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.
Re: VCL block alloc, PERL module issue update
Posted by Mike Haudenschild <mi...@longsight.com>.
Hi Andy,
I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1
management node release. I did notice that libwww was installed to satisfy
dependencies for perl-xml-simple. I didn't do any other tweaking -- just
ran the script and otherwise followed the "normal" management node install
procedure.
A block allocation didn't work, however:
|3394|blockrequest| ---- CRITICAL ----
|3394|blockrequest| 2012-02-06
15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method
"type" via package "RPC::XML::Client::send_request: HTTP server error: you
need" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP
server error: you need"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line
9121.
|3394|blockrequest| ( 0) vcld, die_handler (line: 636)
|3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
|3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
|3394|blockrequest| (-3) blockrequest.pm, process (line: 193)
|3394|blockrequest| (-4) vcld, make_new_child (line: 568)
|3394|blockrequest| (-5) vcld, main (line: 448)
On Mon, Feb 6, 2012 at 12:23, Andy Kurth <an...@ncsu.edu> wrote:
> I updated install_perl_libs.pl in the repository:
>
> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
>
> You should now be able to run it without having to perform any
> additional steps. Please give it a try.
>
> Thanks,
> Andy
>
> On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <mi...@longsight.com>
> wrote:
> > All,
> >
> > I've managed to get around the CRITICAL error I was seeing in the vcld
> log
> > during block allocations. perl-libwww-perl wasn't installed. *sigh*
> > Installing that prior to running install_perl_libs.pl solved the
> problem
> > (should that be added to the install_perl_libs script?). I noticed that
> > there are two listings of PERL-related software required for the
> management
> > node:
> >
> >
> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
> >
> > and
> >
> > https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
> >
> > We might want to consolidate those. I was running from the install docs
> > and didn't even think to check that perl-libwww-perl was installed.
> >
> > Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
> > (which is NOT the most recent version) using the make method from the
> CPAN
> > archive.
> >
> > Note that I'm on CentOS 5.7, clean install and fully updated prior to
> > install VCL management node. There is no package perl-XML-RPC (called
> from
> > the script) available from the repos (with EPEL enabled),
> > and perl-libwww-perl wasn't installed by default.
> >
> > Here's the process I used...
> >
> > 1. Used the 2.2.1 release install_perl_libs.pl script
> > 2. Commented out the line that tells install_perl_libs.pl to retrieve
> > RPC::XML from CPAN (line 285)
> > 3. Ran install_perl_libs.pl
> > 4. Installed RPC-XML 0.71 from CPAN
> > 5. Completed VCL management node install steps from the documentation
> >
> > I went with the lowest-versions of the various dependencies needed by
> > RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate
> any
> > feedback from the list on whether that may have unintended
> consequences...
> >
> > Here's the dependency tree with links:
> >
> > - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
> > - libwww-perl (LWP) 5.801 (
> > https://metacpan.org/release/GAAS/libwww-perl-5.801)
> > - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
> > that some tests FAILED
> > - HTML-Parser 3.33 (
> > https://metacpan.org/release/GAAS/HTML-Parser-3.33)
> > - HTML-Tagest 3.02 (
> > https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
> > - XML-Parser 2.31 (
> > https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
> >
> > Having the most recent perl-libwww-perl from CPAN yielded an install that
> > didn't include LWP::Protocol::https (and the script is trying to make an
> > HTTPS connection). Installing LWP-Protocol-https doesn't solve the
> problem
> > because of stricter SSL certification requirements and hostname
> > verification (
> >
> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
> > ).
> >
> > Many thanks,
> > Mike
> >
> >
> > On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
> >
> >> 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 <mi...@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 <mi...@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 <ac...@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
> >> >>> > mike@longsight.com
> >> >>> > www.longsight.com
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <
> aaron_peeler@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.plscript
> >> >>> >>
> >> >>> >>
> >> >>>
> >>
> 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 <
> >> mike@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 <
> >> mike@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 <
> >> mike@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 <
> >> >>> mike@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.
> >> >>> >>
> >> >>>
> >> >>>
> >> >>
> >>
>
Re: VCL block alloc, PERL module issue update
Posted by Andy Kurth <an...@ncsu.edu>.
I updated install_perl_libs.pl in the repository:
https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
You should now be able to run it without having to perform any
additional steps. Please give it a try.
Thanks,
Andy
On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <mi...@longsight.com> wrote:
> All,
>
> I've managed to get around the CRITICAL error I was seeing in the vcld log
> during block allocations. perl-libwww-perl wasn't installed. *sigh*
> Installing that prior to running install_perl_libs.pl solved the problem
> (should that be added to the install_perl_libs script?). I noticed that
> there are two listings of PERL-related software required for the management
> node:
>
> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
>
> and
>
> https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
>
> We might want to consolidate those. I was running from the install docs
> and didn't even think to check that perl-libwww-perl was installed.
>
> Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
> (which is NOT the most recent version) using the make method from the CPAN
> archive.
>
> Note that I'm on CentOS 5.7, clean install and fully updated prior to
> install VCL management node. There is no package perl-XML-RPC (called from
> the script) available from the repos (with EPEL enabled),
> and perl-libwww-perl wasn't installed by default.
>
> Here's the process I used...
>
> 1. Used the 2.2.1 release install_perl_libs.pl script
> 2. Commented out the line that tells install_perl_libs.pl to retrieve
> RPC::XML from CPAN (line 285)
> 3. Ran install_perl_libs.pl
> 4. Installed RPC-XML 0.71 from CPAN
> 5. Completed VCL management node install steps from the documentation
>
> I went with the lowest-versions of the various dependencies needed by
> RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any
> feedback from the list on whether that may have unintended consequences...
>
> Here's the dependency tree with links:
>
> - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
> - libwww-perl (LWP) 5.801 (
> https://metacpan.org/release/GAAS/libwww-perl-5.801)
> - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
> that some tests FAILED
> - HTML-Parser 3.33 (
> https://metacpan.org/release/GAAS/HTML-Parser-3.33)
> - HTML-Tagest 3.02 (
> https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
> - XML-Parser 2.31 (
> https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
>
> Having the most recent perl-libwww-perl from CPAN yielded an install that
> didn't include LWP::Protocol::https (and the script is trying to make an
> HTTPS connection). Installing LWP-Protocol-https doesn't solve the problem
> because of stricter SSL certification requirements and hostname
> verification (
> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
> ).
>
> Many thanks,
> Mike
>
>
> On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
>
>> 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 <mi...@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 <mi...@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 <ac...@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
>> >>> > mike@longsight.com
>> >>> > www.longsight.com
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aa...@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 <
>> mike@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 <
>> mike@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 <
>> mike@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 <
>> >>> mike@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.
>> >>> >>
>> >>>
>> >>>
>> >>
>>
Re: VCL block alloc, PERL module issue update
Posted by Mike Haudenschild <mi...@longsight.com>.
All,
I've managed to get around the CRITICAL error I was seeing in the vcld log
during block allocations. perl-libwww-perl wasn't installed. *sigh*
Installing that prior to running install_perl_libs.pl solved the problem
(should that be added to the install_perl_libs script?). I noticed that
there are two listings of PERL-related software required for the management
node:
https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
and
https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
We might want to consolidate those. I was running from the install docs
and didn't even think to check that perl-libwww-perl was installed.
Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
(which is NOT the most recent version) using the make method from the CPAN
archive.
Note that I'm on CentOS 5.7, clean install and fully updated prior to
install VCL management node. There is no package perl-XML-RPC (called from
the script) available from the repos (with EPEL enabled),
and perl-libwww-perl wasn't installed by default.
Here's the process I used...
1. Used the 2.2.1 release install_perl_libs.pl script
2. Commented out the line that tells install_perl_libs.pl to retrieve
RPC::XML from CPAN (line 285)
3. Ran install_perl_libs.pl
4. Installed RPC-XML 0.71 from CPAN
5. Completed VCL management node install steps from the documentation
I went with the lowest-versions of the various dependencies needed by
RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any
feedback from the list on whether that may have unintended consequences...
Here's the dependency tree with links:
- RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
- libwww-perl (LWP) 5.801 (
https://metacpan.org/release/GAAS/libwww-perl-5.801)
- URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
that some tests FAILED
- HTML-Parser 3.33 (
https://metacpan.org/release/GAAS/HTML-Parser-3.33)
- HTML-Tagest 3.02 (
https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
- XML-Parser 2.31 (
https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
Having the most recent perl-libwww-perl from CPAN yielded an install that
didn't include LWP::Protocol::https (and the script is trying to make an
HTTPS connection). Installing LWP-Protocol-https doesn't solve the problem
because of stricter SSL certification requirements and hostname
verification (
http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
).
Many thanks,
Mike
On Wed, Feb 1, 2012 at 11:44, Andy Kurth <an...@ncsu.edu> wrote:
> 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 <mi...@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 <mi...@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 <ac...@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
> >>> > mike@longsight.com
> >>> > www.longsight.com
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aa...@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 <
> mike@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 <
> mike@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 <
> mike@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 <
> >>> mike@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.
> >>> >>
> >>>
> >>>
> >>
>
Re: VCL block alloc, PERL module issue update
Posted by Andy Kurth <an...@ncsu.edu>.
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 <mi...@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 <mi...@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 <ac...@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
>>> > mike@longsight.com
>>> > www.longsight.com
>>> >
>>> >
>>> >
>>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aa...@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 <mike@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 <mi...@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 <mike@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 <
>>> mike@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.
>>> >>
>>>
>>>
>>