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 <andy_ku...@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 <m...@longsight.com> > wrote: > > Here's the output: > > > > @@@@@ > > XML::LibXML not found > > > > You may ignore the warnings about XML::LibXML not being present, > if > > you plan only to use the XML::Parser-based parsing engine. The use > > of XML::LibXML is completely optional. > > @@@@@ > > > > WARNING: MIN_PERL_VERSION is not a known parameter. > > WARNING: META_MERGE is not a known parameter. > > WARNING: LICENSE is not a known parameter. > > Warning: prerequisite LWP 5.834 not found. We have 5.805. > > Warning: prerequisite Test::More 0.94 not found. We have 0.62. > > 'LICENSE' is not a known MakeMaker parameter name. > > 'META_MERGE' is not a known MakeMaker parameter name. > > 'MIN_PERL_VERSION' is not a known MakeMaker parameter name. > > Writing Makefile for RPC::XML > > > > > > > > On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild <m...@longsight.com> > wrote: > > > >> Hi Aaron, > >> > >> You're right, RPC-XML wasn't installed, although perl-libwww-perl is > >> installed and updated. > >> > >> Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get > errors > >> when I run Makefile about various missing prerequisites on a clean > CentOS > >> install.) > >> > >> Thanks, > >> Mike > >> > >> On Tue, Jan 31, 2012 at 16:49, Aaron Coburn <acob...@amherst.edu> > wrote: > >> > >>> Oh. It looks like RPC-XML is not installed. > >>> > >>> You can verify that by using this command: > >>> > >>> perl -MRPC::XML -e "print 'have a nice day'" > >>> > >>> If you get errors, the module isn't installed. If the script seems > >>> friendly, then the module is installed. > >>> > >>> If the module is not installed, download it from here: > >>> http://search.cpan.org/dist/RPC-XML/ > >>> > >>> unpack it and install it like so: > >>> > >>> perl Makefile.PL > >>> make && make test > >>> sudo make install > >>> > >>> Then try the command again that I listed above. > >>> > >>> > >>> > >>> On Jan 31, 2012, at 4:42 PM, Mike Haudenschild wrote: > >>> > >>> > Hi Aaron, > >>> > > >>> > I get the following errors running install_perl_libs from trunk, on > >>> CentOS > >>> > 5.7 fully updated: > >>> > > >>> > *No package perl-CPAN available.* > >>> > *WARNING: unexpected output returned while installing Linux package: > >>> > 'perl-CPAN'* > >>> > *this has happened since my first install, but doesn't seem to be a > >>> problem > >>> > since cpan is already installed in CentOS base > >>> > > >>> > *No package perl-RPC-XML available.* > >>> > *WARNING: unexpected output returned while installing Linux package: > >>> > 'perl-RPC-XML'* > >>> > *this has also happened since my first install, but I've never been > >>> able to > >>> > resolve this. I thought perhaps the CPAN commands issued at the end > of > >>> the > >>> > install script installed RPC::XML from CPAN...? > >>> > > >>> > All of the PERL module installs throw: > >>> > *Unknown command 'notest'. Type ? for help.* > >>> > > >>> > Two PERL modules fail to install: > >>> > > >>> > *Attempting to install Perl module using CPAN: 'Object::InsideOut'* > >>> > *Unknown command 'notest'. Type ? for help.* > >>> > *checking if Object::InsideOut Perl module is installed...* > >>> > *Perl module Object::InsideOut appears to be installed but the > version > >>> > could not be determined* > >>> > *command: perl -e "eval \"use Object::InsideOut\"; print > >>> > \$Object::InsideOut::VERSION" 2>&1* > >>> > *output:* > >>> > *ERROR: failed to install Perl module: 'Object::InsideOut'* > >>> > > >>> > > >>> > *Attempting to install Perl module using CPAN: 'RPC::XML'* > >>> > *Unknown command 'notest'. Type ? for help.* > >>> > *checking if RPC::XML Perl module is installed...* > >>> > *Perl module RPC::XML appears to be installed but the version could > not > >>> be > >>> > determined* > >>> > *command: perl -e "eval \"use RPC::XML\"; print \$RPC::XML::VERSION" > >>> 2>&1* > >>> > *output:* > >>> > *ERROR: failed to install Perl module: 'RPC::XML'* > >>> > > >>> > Thanks!! > >>> > Mike > >>> > > >>> > -- > >>> > *Mike Haudenschild* > >>> > Education Systems Manager > >>> > Longsight Group > >>> > (740) 599-5005 x809 > >>> > m...@longsight.com > >>> > www.longsight.com > >>> > > >>> > > >>> > > >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler <aaron_pee...@ncsu.edu> > >>> wrote: > >>> > > >>> >> Hi Mike, > >>> >> > >>> >> Apologies for not responding on this. > >>> >> > >>> >> Are you still seeing this issue with your block allocations? > >>> >> > >>> >> If so you could try to use the latest install_perl_libs.pl script > >>> >> > >>> >> > >>> > https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl > >>> >> > >>> >> Aaron > >>> >> > >>> >> On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild < > m...@longsight.com > >>> > > >>> >> wrote: > >>> >>> Dev team, > >>> >>> > >>> >>> I would very much appreciate guidance on whether I should try > defining > >>> >> (or > >>> >>> bypassing) the SSL cert variables in the PERL scripts, or if I > >>> should/can > >>> >>> downgrade the applicable PERL modules to older known-working > versions > >>> to > >>> >>> workaround this issue altogether. > >>> >>> > >>> >>> The log was telling me that LWP::Protocol::https was required, and > >>> it's > >>> >> not > >>> >>> installed by the install_perl_libs script (because > >>> LWP::Protocol::https > >>> >> was > >>> >>> recently split out from libwww-perl?). Once installed, however, I > get > >>> >>> static as shown in the logs below. > >>> >>> > >>> >>> I'm dead in the water with block allocations. Thanks very much for > >>> any > >>> >>> help. > >>> >>> > >>> >>> Regards, > >>> >>> Mike > >>> >>> > >>> >>> > >>> >>> On Tue, Jan 24, 2012 at 21:00, Mike Haudenschild < > m...@longsight.com> > >>> >> wrote: > >>> >>> > >>> >>>> Good evening, > >>> >>>> > >>> >>>> I apologize for the numerous emails, but as I continue working > >>> through > >>> >>>> this something new popped up: > >>> >>>> > >>> >>>> I managed to get LWP::Protocol::https to install by first updating > >>> >>>> Net::SSLLeay with CPAN. > >>> >>>> > >>> >>>> However, when making a block allocation I now get this in the log: > >>> >>>> > >>> >>>> |4978|blockrequest| ---- CRITICAL ---- > >>> >>>> |4978|blockrequest| 2012-01-24 20 > >>> >> :53:45|4978|blockrequest|vcld:die_handler(636)|Can't > >>> >>>> locate object method "type" via package > >>> "RPC::XML::Client::send_request: > >>> >>>> HTTP server error:* Can't connect to vclserver:443< > >>> >> http://urichmond.longsight.com:443>(certificate verify failed) > >>> >>>> *" (perhaps you forgot to load "RPC::XML::Client::send_request: > HTTP > >>> >>>> server error: Can't connect to server.domain.com:443 (certificate > >>> >> verify > >>> >>>> failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. > >>> >>>> |4978|blockrequest| ( 0) vcld, die_handler (line: 636) > >>> >>>> |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) > >>> >>>> |4978|blockrequest| (-2) blockrequest.pm, process_block_time > (line: > >>> >> 373) > >>> >>>> |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) > >>> >>>> |4978|blockrequest| (-4) vcld, make_new_child (line: 568) > >>> >>>> |4978|blockrequest| (-5) vcld, main (line: 448) > >>> >>>> > >>> >>>> 2012-01-24 20 > >>> >> :53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest > >>> >>>> destructor called, address: f7be070 > >>> >>>> 2012-01-24 20 > :53:45|4978|blockrequest|State.pm:DESTROY(848)|number > >>> of > >>> >>>> database handles state process created: 1 > >>> >>>> 2012-01-24 20:53:45|4138|vcld:REAPER(718)|VCL process exited for > >>> >>>> reservation <unknown>, PID: 4978, signal: CHLD > >>> >>>> > >>> >>>> My limited understanding of PERL is at play here, but from my > >>> research > >>> >> it > >>> >>>> seems that updated versions of LWP::UserAgent do strict SSL > >>> certificate > >>> >>>> checking. (We do have a CA-issued SSL cert installed for the VCL > Web > >>> >> front > >>> >>>> end.) > >>> >>>> > >>> >>>> > >>> >>>> > >>> >> > >>> > http://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates > >>> >>>> > >>> >>>> I'd very much appreciate any feedback from experts on the list. > >>> >>>> > >>> >>>> Many thanks, > >>> >>>> Mike > >>> >>>> > >>> >>>> > >>> >>>> On Tue, Jan 24, 2012 at 20:12, Mike Haudenschild < > m...@longsight.com > >>> >>> wrote: > >>> >>>> > >>> >>>>> I've been looking into this further, and I've found what appears > to > >>> be > >>> >> a > >>> >>>>> missing PERL module (LWP::Protocol::https). I attempted to > install > >>> it > >>> >>>>> manually with CPAN, but I get two test errors. I've attached the > >>> CPAN > >>> >>>>> error message immediately below, and the section of vcld.log from > >>> the > >>> >>>>> moment I save the block allocation. > >>> >>>>> > >>> >>>>> Thanks to all, > >>> >>>>> Mike > >>> >>>>> > >>> >>>>> ------ > >>> >>>>> > >>> >>>>> t/apache....# Failed test 1 in t/apache.t at line 12 > >>> >>>>> # t/apache.t line 12 is: ok($res->is_success); > >>> >>>>> # Failed test 2 in t/apache.t at line 13 > >>> >>>>> # t/apache.t line 13 is: ok($res->content =~ /Apache Software > >>> >>>>> Foundation/); > >>> >>>>> t/apache....FAILED tests 1-2 > >>> >>>>> Failed 2/2 tests, 0.00% okay > >>> >>>>> Failed Test Stat Wstat Total Fail Failed List of Failed > >>> >>>>> > >>> >>>>> > >>> >> > >>> > ------------------------------------------------------------------------------- > >>> >>>>> t/apache.t 2 2 100.00% 1-2 > >>> >>>>> Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% > >>> okay. > >>> >>>>> make: *** [test_dynamic] Error 255 > >>> >>>>> /usr/bin/make test -- NOT OK > >>> >>>>> Running make install > >>> >>>>> make test had returned bad status, won't install without force > >>> >>>>> > >>> >>>>> ------ > >>> >>>>> > >>> >>>>> > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: > >>> >> process(166)|owner > >>> >>>>> email: root@localhost > >>> >>>>> Use of uninitialized value in concatenation (.) or string at > >>> >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167 > (#1) > >>> >>>>> (W uninitialized) An undefined value was used as if it were > >>> already > >>> >>>>> defined. It was interpreted as a "" or a 0, but maybe it was > a > >>> >>>>> mistake. > >>> >>>>> To suppress this warning assign a defined value to your > >>> variables. > >>> >>>>> > >>> >>>>> To help you figure out what was undefined, perl tells you what > >>> >>>>> operation > >>> >>>>> you used the undefined value in. Note, however, that perl > >>> >> optimizes > >>> >>>>> your > >>> >>>>> program and the operation displayed in the warning may not > >>> >> necessarily > >>> >>>>> appear literally in your program. For example, "that $foo" is > >>> >>>>> usually optimized into "that " . $foo, and the warning will > refer > >>> >> to > >>> >>>>> the concatenation (.) operator, even though there is no . in > your > >>> >>>>> program. > >>> >>>>> > >>> >>>>> > >>> >>>>> |3518|blockrequest| ---- WARNING ---- > >>> >>>>> |3518|blockrequest| 2012-01-24 19 > >>> >> :40:35|3518|blockrequest|vcld:warning_handler(610)|Use > >>> >>>>> of uninitialized value in concatenation (.) or string at > >>> >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167. > >>> >>>>> |3518|blockrequest| ( 0) vcld, warning_handler (line: 610) > >>> >>>>> |3518|blockrequest| (-1) blockrequest.pm, process (line: 167) > >>> >>>>> |3518|blockrequest| (-2) vcld, make_new_child (line: 568) > >>> >>>>> |3518|blockrequest| (-3) vcld, main (line: 448) > >>> >>>>> > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: > >>> >> process(167)|help > >>> >>>>> address: > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: > >>> >> process(172)|updated > >>> >>>>> process flag on blocktime_id= 4 > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: > >>> >> process(192)|processing > >>> >>>>> blocktime_id= 4 pass 1 > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm: > >>> >> xmlrpc_call(9105)|argument_string= > >>> >>>>> XMLRPCprocessBlockTime 4 1 > >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm: > mail(1268)|SUCCESS > >>> -- > >>> >>>>> Sending mail To: 0, PROBLEM -- vcld:die_handler(636)|test > >>> >>>>> > >>> >>>>> |3518|blockrequest| ---- CRITICAL ---- > >>> >>>>> |3518|blockrequest| 2012-01-24 19 > >>> >> :40:35|3518|blockrequest|vcld:die_handler(636)|Can't > >>> >>>>> locate object method "type" via package > >>> >> "RPC::XML::Client::send_request: > >>> >>>>> HTTP server error: Protocol scheme 'https' is not supported > >>> >>>>> (LWP::Protocol::https not installed)" (perhaps you forgot to load > >>> >>>>> "RPC::XML::Client::send_request: HTTP server error: Protocol > scheme > >>> >> 'https' > >>> >>>>> is not supported (LWP::Protocol::https not installed)"?) at > >>> >>>>> /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. > >>> >>>>> |3518|blockrequest| ( 0) vcld, die_handler (line: 636) > >>> >>>>> |3518|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) > >>> >>>>> |3518|blockrequest| (-2) blockrequest.pm, process_block_time > (line: > >>> >> 373) > >>> >>>>> |3518|blockrequest| (-3) blockrequest.pm, process (line: 193) > >>> >>>>> |3518|blockrequest| (-4) vcld, make_new_child (line: 568) > >>> >>>>> |3518|blockrequest| (-5) vcld, main (line: 448) > >>> >>>>> > >>> >>>>> 2012-01-24 19 > >>> >> :40:35|3518|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest > >>> >>>>> destructor called, address: 96b7c1c > >>> >>>>> 2012-01-24 19 > :40:35|3518|blockrequest|State.pm:DESTROY(848)|number > >>> of > >>> >>>>> database handles state process created: 1 > >>> >>>>> 2012-01-24 19:40:35|3459|vcld:REAPER(718)|VCL process exited for > >>> >>>>> reservation <unknown>, PID: 3518, signal: CHLD > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> On Tue, Jan 24, 2012 at 12:05, Mike Haudenschild < > >>> m...@longsight.com > >>> >>> wrote: > >>> >>>>> > >>> >>>>>> Hello, VCL dev -- > >>> >>>>>> > >>> >>>>>> I've seen three instances of "relaim" errors on my VCL instance > >>> today > >>> >> -- > >>> >>>>>> machines that vcld couldn't seem to reach, although they > appeared > >>> >> running > >>> >>>>>> on the ESXi console. > >>> >>>>>> > >>> >>>>>> It started when I began creating block allocations (which did > not > >>> >> appear > >>> >>>>>> to work). In both cases there seemed to be text in the log > >>> regarding > >>> >>>>>> incorrect SQL syntax. > >>> >>>>>> > >>> >>>>>> After the errors, the affected machines showed as "failed" in > the > >>> VCL > >>> >>>>>> front end, but eventually reloaded and appear to be working > fine. > >>> >>>>>> > >>> >>>>>> Regular, individual reservations appear to be working fine. > I've > >>> >>>>>> attached both snippets of log and would appreciate any feedback. > >>> >>>>>> > >>> >>>>>> Many thanks, > >>> >>>>>> Mike > >>> >>>>>> > >>> >>>>> > >>> >>>>> > >>> >>>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Aaron Peeler > >>> >> Program Manager > >>> >> Virtual Computing Lab > >>> >> NC State University > >>> >> > >>> >> All electronic mail messages in connection with State business which > >>> >> are sent to or received by this account are subject to the NC Public > >>> >> Records Law and may be disclosed to third parties. > >>> >> > >>> > >>> > >> >
