<div dir="ltr"><div><div><div><div><div>Oi Kleber,<br><br></div><div>Não uso Windows há muitos anos - menos ainda como servidores web - mas, ao que parece, esse erro do OpenSSL acontece quando a versão que você instalou não é compatível com a sua arquitetura (por exemplo, 32 bits x 64 bits), ou quando o Apache não encontra todas as dependências da biblioteca - problemas de %PATH ou coisa que o valha.<br></div><br></div>Experimenta ir no diretório onde o OpenSSL foi instalado e copiar os arquivos ssleay32.dll, libeay32.dll e openssl.exe para dentro do diretório bin do apache (normalmente "apache/bin", mas acho que depende de onde você instalou o seu Apache) e reinicia. Se eles já existirem, manda sobrescrever (faça um backup antes, óbvio). Reza a lenda que botar no C:\Windows\System32 também ajuda. Mas isso tudo é dica de Google, não posso afirmar nada nem sobre a corretude nem sobre problemas de segurança associados.<br><br></div>Boa sorte!<br><br>[]s<br></div><br></div>-b<br><div><div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 13, 2014 at 7:30 PM, <span dir="ltr"><<a href="mailto:payback@oi.com.br" target="_blank">payback@oi.com.br</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div style="FONT-SIZE:12pt;FONT-FAMILY:'Calibri';COLOR:#000000">
<div>Olá Breno ,</div>
<div> </div>
<div>Agradeço sua gentileza em responder. </div>
<div> </div>
<div>Sou leigo em perl ( gosto de pesquisar e aprender ).</div>
<div>Resolvi o problema retirando todos os require dos scripts. </div>
<div>Está funcionando corretamente e o tempo de resposta é bem melhor.</div>
<div>( levei uns 4 dias para fazer isto em todos os scripts )</div>
<div> </div>
<div>Tomo a liberdade em abordar outro assunto : Modulo SSL no Apache
2.2.22</div>
<div> </div>
<div>Depois de muita pesquisa instalei no apache 2.2.22 o modulo mod_ssl e está
funcionado.</div>
<div>Criei o certificado com o openssl-win32 ( <a href="http://slproweb.com/products/Win32OpenSSL.html" target="_blank">http://slproweb.com/products/Win32OpenSSL.html</a>
).</div>
<div> </div>
<div>Utilizei a configuração padrão do apache para ssl ( conf / extra /
http-ssl.conf ).</div>
<div> </div>
<div>Nota - instalei em dois computadores : windows 7 e windows 2003
server.</div>
<div> </div>
<div>Observei que está acontecendo o seguinte :</div>
<div> </div>
<div>- Ao executar no modo seguro em <a href="https://localhost" target="_blank">https://localhost</a> o meu aplicativo roda normalmente
( tem um bom tempo de resposta ) </div>
<div>nas duas máquinas ( win7 e win2003 ) apesar do windows declarar certificado
não seguro.</div>
<div> </div>
<div>- Quando executo de outra forma ( <a href="https://win7server" target="_blank">https://win7server</a> ou <a href="https://win2003" target="_blank">https://win2003</a> na console ou em rede ) percebo
, através do log ,</div>
<div>que o apache reinicializa várias vezes e o tempo de resposta está
altíssimo. </div>
<div> </div>
<div>Nota - estou recebendo as seguintes mensagens de erro :</div>
<div> </div>
<div>[1] - Relatando erro enfileirado: aplicativo com falha httpd.exe, versão
2.2.22.0, módulo com falha ssleay32.dll, </div>
<div>versão 1.0.1.10, endereço com falha 0x00023cb1. ( win7 e win2003 )
</div>
<div> </div>
<div>[2] - wuaueng.dll (840) SUS20ClientDataStore: Falha na
recuperação/restauração do banco de dados com erro inesperado -551.</div>
<div>( somente no wi2003 e acho que este erro não tem nada a ver com mod_ssl no
apache )</div>
<div> </div>
<div>[3] - Ao executar o windows update no win2003 recebo a seguinte
mensagem : Número do erro: 0xC8000227</div>
<div> </div>
<div>Você conhece este assunto modo ssl no apache e pode me dar alguma dica
?</div>
<div> </div>
<div>Conhece algum fórum especializado em apache onde eu possa postar este
assunto ?</div>
<div> </div>
<div>Mais uma vez agradeço a atenção dispensada , </div>
<div> </div>
<div>kleber</div>
<div> </div>
<div style="FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibri";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline">
<div style="FONT:10pt tahoma">
<div> </div>
<div style="BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title="breno@rio.pm.org" href="mailto:breno@rio.pm.org" target="_blank">breno</a> </div>
<div><b>Sent:</b> Saturday, December 13, 2014 1:12 PM</div>
<div><b>To:</b> <a title="cascavel-pm@pm.org" href="mailto:cascavel-pm@pm.org" target="_blank">Cascavel Perl Mongers</a> </div>
<div><b>Subject:</b> Re: [Cascavel-pm] mod_perl</div></div></div>
<div> </div></div>
<div style="FONT-SIZE:small;TEXT-DECORATION:none;FONT-FAMILY:"Calibri";FONT-WEIGHT:normal;COLOR:#000000;FONT-STYLE:normal;DISPLAY:inline"><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>Oi Kleber,<br><br></div>desculpa não ter respondido antes, só vi o email
agora :(<br><br></div>Ainda está com problemas para carregar funções? O mod_perl
é uma ferramenta poderosa mas um tanto confusa mesmo - por essas e outras que o
desenvolvimento Perl moderno para web foge dessas implementações e prefere
soluções como PSGI.<br><br></div>Pela sua mensagem, parece que o mod_perl está
tendo dificuldades em encontrar a função "grava_conf" criada pelo seu código.
Estou supondo que ela é criada e importada ao carregar o arquivo
"c:\payback\dosbox.plx", mas é só achismo meu - me corrija se estiver
errado!<br><br></div>
<div>Se é esse o caso, o cache do mod_perl pode estar se perdendo. Ele compila
uma vez, grava no namespace ModPerl::ROOT::ModPerl::Registry:::blablabla, e
esquece. Na hora que você executa em outro script, ele ve que o arquivo já está
compilado em memória e pula, mas como o seu arquivo atual foi gravado em *outro*
namespace do mod_perl, ele não acha a função.<br><br></div>
<div>Uma solução rápida para você é descobrir em que módulo a função
"grava_conf" é definida e chamar ela com o full namespace em vez de apenas como
"grava_conf()". Por exemplo, suponha que ela tenha sido definida no módulo
Payback::Utils:<br><br></div>
<div>---------8<---------<br></div>
<div>package Payback::Utils;<br></div>
<div>use strict;<br></div>
<div>use warnings;<br><br></div>
<div>sub grava_conf {<br> ...<br>}<br><br>1;<br></div>
<div>--------->8---------<br></div>
<div>
<div><br>Daí, nos lugares onde você usa, em vez de dizer:<br><br><br>require
'c:\\payback\\dosbox.plx';<br>grava_conf($conf,$prog);<br><br><br></div>
<div>Você tem que dizer:<br></div>
<div><br>require
'c:\\payback\\dosbox.plx';<br>Payback::Utils::grava_conf($conf,$prog);<br><br></div>
<div>Isso deve resolver o seu problema de função não encontrada dentro do
mod_perl (espero!)<br><br><br></div>
<div>Dito isso, acho importante citar que, na maioria dos casos, ter "require"
escrito assim não é uma boa prática hoje em dia. Há vários motivos para isso
(além do problema que você já está experimentando): a dependência via "require"
é avaliada durante o tempo de execução, não de compilação, deixando a execução
do seu programa potencialmente mais lenta; o "require" exige o caminho do
arquivo no sistema de arquivos em vez de abstrair isso pra você e acaba deixando
o seu código menos portátil - imagine ter que rodar seu código Windows em um
Linux, você vai ter que mudar o "c:\" e as barras em tudo! Mesmo no Windows,
imagine ter que botar seu programa em outro diretório? Finalmente, o require
estimula carregar scripts ".pl" quando a boa prática de hoje sugere que você
separe seu programa logicamente em módulos, facilitando a reutilização de
código, a identificação de erros e a manutenção do seu programa. Ou seja, em vez
de 'c:\\payback\\dosbox.plx',você teria um arquivo (por exemplo) "lib/Dosbox.pm"
com:<br><br>---------8<---------<br></div>
<div>package Dosbox;<br></div>
<div>use strict;<br>use warnings;<br><br></div>
<div># funcoes do dosbox.plx<br><br>1;<br>--------->8---------<br><br></div>
<div>e em vez de chamar como:<br><br>require
'c:\\payback\\dosbox.plx';<br><br></div>
<div>você colocaria um:<br><br>use Dosbox;<br><br></div>
<div>no topo do seu código.<br></div>
<div> </div>
<div>Idealmente, o código dentro do script "c:\\payback\dosbox.plx" seria
refatorado em módulo(s) com namespace(s) significativo(s). Mesmo deixar tudo
desse arquivo junto em um grande "Dosbox.pm" já seria potencialmente benéfico.
Se o script de antes não apenas definia funções mas também executava algum
código, declarava variáveis, etc, você pode iniciar o refactoring colocando todo
o código dentro de uma grande sub e ir separando aos poucos. Isso é
particularmente importante se você tem muitas variáveis "my" e está em ambiente
mod_perl, já que o comportamento do mod_perl pode tornar o conteúdo delas
inesperado.<br><br></div>
<div>Espero ter ajudado! E desculpe novamente pela demora.<br><br></div>
<div>[]s<br><br></div>
<div>-b<br></div>
<div> </div>
<div>
<div> </div></div></div></div>
<div class="gmail_extra">
<div> </div>
<div class="gmail_quote">On Sun, Nov 30, 2014 at 5:33 PM, kleber <span dir="ltr"><<a href="mailto:payback@oi.com.br" target="_blank">payback@oi.com.br</a>></span> wrote:
<blockquote class="gmail_quote" style="PADDING-LEFT:1ex;MARGIN:0px 0px 0px 0.8ex;BORDER-LEFT:#ccc 1px solid">Olá
Srs ,<br><br>Instalei o mod_perl no meu computador sendo que ao
iniciá-lo recebo a seguinte mensagem :<br><br>[Sun Nov 30 09:29:28 2014]
[notice] Apache/2.2.22 (Win32) PHP/5.2.8 mod_apreq2-20090110/2.8.0
mod_perl/2.0.7 Perl/v5.16.3 configured -- resuming normal
operations<br><br>Utilizei a seguinte configuração no apache
:<br><br>PerlModule ModPerl::RegistryBB<br><Files ~
"\.plx$"><br>SetHandler perl-script<br>PerlResponseHandler
ModPerl::RegistryBB::handler<br>PerlOptions +ParseHeaders<br>Options -Indexes
MultiViews FollowSymLinks +ExecCGI<br>PerlSendHeader On<br>Order
allow,deny<br>Allow from all<br></Files><br><br>Consigo executar vários
scripts em mod_perl porém estou tendo problema com scripts que tem as
instruções
:<br><br>
require
'c:\\payback\\dosbox.plx';<br>
grava_conf($conf,$prog);<br><br>Quando executo o script com esta
característica recebo a seguinte mensagem de erro :<br><br>[error]Undefined
subroutine
&ModPerl::ROOT::ModPerl::<u></u>RegistryBB::C_3a_Payback_<u></u>Contabil_Operacao_Fluxo_<u></u>Formulario_2eplx::grava_conf
called at C:/Payback/Formulario.plx line 47.<br><br>Nota - Em ambiente cgi (
sem mod_perl ) todos os scripts são executados normalmente ( sem problemas
).<br><br>Pesquisando na internet encontrei o seguinte texto no <a href="http://perl.apache.org" target="_blank">perl.apache.org</a> : ( <a href="http://perl.apache.org/docs/1.0/guide/porting.html" target="_blank">http://perl.apache.org/docs/1.<u></u>0/guide/porting.html</a>
- See Names collisions with Modules and libs.) :<br><br>There are three
solutions for this:<br><br>.Solution 1<br><br>The first two faulty scenarios
can be solved by placing your library modules in a subdirectory structure so
that they have different path prefixes.<br>The file system layout will be
something like:<br>./tool1/Tool1/Foo.pm<br>./tool1/<a href="http://tool1.pl" target="_blank">tool1.pl</a><br>./tool2/Tool2/Foo.pm<br>./tool2/<a href="http://tool2.pl" target="_blank">tool2.pl</a><br><br>And modify the
scripts:<br>use Tool1::Foo;<br>use Tool2::Foo;<br><br>For require() (scenario
number 2) use the following:<br>./tool1/tool1-lib/<a href="http://config.pl" target="_blank">config.pl</a><br>./tool1/<a href="http://tool1.pl" target="_blank">tool1.pl</a><br>./tool2/tool2-lib/<a href="http://config.pl" target="_blank">config.pl</a><br>./tool2/<a href="http://tool2.pl" target="_blank">tool2.pl</a><br><br>And each script contains
respectively:<br>use lib qw(.);<br>require "tool1-lib/<a href="http://config.pl" target="_blank">config.pl</a>";<br><br>use lib
qw(.);<br>require "tool2-lib/<a href="http://config.pl" target="_blank">config.pl</a>";<br><br>This solution isn't good, since while it
might work for you now, if you add another script that wants to use the same
module or <a href="http://config.pl" target="_blank">config.pl</a> file, it
would fail as we saw in the third scenario.<br><br>Let's see some better
solutions.<br><br>.Solution 2<br><br>Another option is to use a full path to
the script, so it will be used as a key in %INC;<br>require
"/full/path/to/the/<a href="http://config.pl" target="_blank">config.pl</a>";<br><br>This solution solves the problem of the
first two scenarios. I was surprised that it worked for the third scenario as
well!<br><br>With this solution you lose some portability.<br>If you move the
tool around in the file system you will have to change the base directory or
write some additional script that will automatically update the hardcoded path
after it was moved.<br>Of course you will have to remember to invoke
it.<br><br>.Solution 3<br><br>Make sure you read all of this
solution.<br><br>Declare a package name in the required files! It should be
unique in relation to the rest of the package names you use. %INC will then
use the unique package name for the key.<br>It's a good idea to use at least
two-level package names for your private modules, e.g. MyProject::Carp and not
Carp, since the latter will collide with an existing standard package.<br>Even
though a package may not exist in the standard distribution now, a package may
come along in a later distribution which collides with a name you've
chosen.<br>Using a two part package name will help avoid this
problem.<br><br>Even a better approach is to use three level naming, like
CompanyName::ProjectName::<u></u>Module, which is most unlikely to have
conflicts with later Perl releases.<br>Foresee problems like this and save
yourself future trouble.<br><br>What are the implications of package
declaration?<br><br>Without package declarations, it is very convenient to
use() or require() files because all the variables and subroutines are part of
the main:: package.<br>Any of them can be used as if they are part of the main
script. With package declarations things are more awkward.<br>You have to use
the Package::function() method to call a subroutine from Package and to access
a global variable $foo inside the same package you have to write
$Package::foo.<br><br>Lexically defined variables, those declared with my ()
inside Package will be inaccessible from outside the package.<br><br>You can
leave your scripts unchanged if you import the names of the global variables
and subroutines into the namespace of package main:: like this:<br>use Module
qw(:mysubs sub_b $var1 :myvars);<br><br>You can export both subroutines and
global variables. Note however that this method has the disadvantage of
consuming more memory for the current process.<br><br>See perldoc Exporter for
information about exporting other variables and symbols.<br><br>This
completely covers the third scenario. When you use different module names in
package declarations, as explained above, you cover the first two as
well.<br><br>Comentário - Estas alternativas inviabiliza a utilização do
mod_perl em meu ambiente sistêmico ( existem vários scripts que utilizam a
instrução require ) e<br>não seria sensato ter que multiplicá-los para
individualizar
nomes.<br><br>______________________________<u></u>______________________________<u></u>______________________________<u></u>__________<br><br>Localizei
também este texto na internet e não entendi ( meu conhecimento em perl é
limitado )<br><br>Code Caching Effects ( <a href="http://www.informit.com/articles/article.aspx?p=23010&seqNum=4" target="_blank">http://www.informit.com/<u></u>articles/article.aspx?p=23010&<u></u>seqNum=4</a>
)<br><br>Recall that mod_perl caches compiled scripts.<br>This helps it run
scripts faster, but what happens if you change a script? Does mod_perl
continue to execute<br>the cached version? Nope. Apache::Registry keeps track
of the scripts that it has run and checks the modification date of the
original file when a script is requested again.<br>If the date has changed, it
recompiles the script and the new version is used instead.<br>You can verify
this for yourself. Request a script, and then change it and click the Reload
button in your browser.<br>You should see the changed output.Then change the
script back and click Reload again.You should see the original output.That's
what you expect and want to happen.2<br><br>However, this behavior doesn't
apply to modules pulled into your script via use or require.<br>If you change
those files, the changes won't be noticed until you restart the
server.<br>Another workaround for this problem is to use the Apache::StatINC
module, which forces Apache to check the last modification time even for
modules referenced from use or require statements.<br>This is a technique best
used on a development server, because it slows down Apache. Run perldoc
Apache::StatINC from the command line for more information.<br><br>Script
caching also is responsible for another mysterious problem.<br>If you use or
require a library file, that file's code is pulled in to your script,
compiled, and cached, as usual.<br>If the file doesn't contain a package
declaration to specify a namespace, however, the code goes into your script's
own namespace.<br>This is main when you run scripts in standalone mode, but
scripts run in their own unique namespace under mod_perl.<br>If your script is
called <a href="http://script.pl" target="_blank">script.pl</a>, for example,
the namespace might be
&Apache::ROOT::cgi_2dperl::<u></u>script_2epl.<br>Normally, having unique
namespaces per script is a good thing, because it helps keep scripts that are
run under a given httpd child from colliding with each other in the main
namespace.<br>But it causes a problem for unpackaged library code. Here's why:
Suppose you run your script <a href="http://script.pl" target="_blank">script.pl</a> that uses a library file MyLib.pm containing a
function lib_func(). <a href="http://script.pl" target="_blank">script.pl</a>
will execute properly.<br>Now suppose you have a second script, <a href="http://script2.pl" target="_blank">script2.pl</a>, that wants to use
MyLib.pm, too.When the second script, executes, mod_perl, sees the use or
require line for the library file,<br>notices that the file has already been
processed and cached, and doesn't bother to recompile it.Then when <a href="http://script2.pl" target="_blank">script2.pl</a> calls lib_func() from
the library file, an error occurs:<br><br>[error] Undefined
subroutine<br>&Apache::ROOT::cgi_2dperl::<u></u>script2_2epl::lib_func
called<br><br>This happens because functions in the library file have been
compiled, but they're in the namespace for <a href="http://script.pl" target="_blank">script.pl</a>, not <a href="http://script2.pl.To" target="_blank">script2.pl.To</a> fix this problem,<br>make sure the library
file includes a package declaration, and then invoke its functions using the
package identifier. MyLib.pm can be written like this:<br>package
MyLib;<br><br>sub lib_func<br>{<br> ...<br>}<br>...<br><br>After making
that change, your scripts should invoke MyLib::lib_func() rather than
lib_func().<br><br>Alguém sabe como resolver este problema ?<br><br>Agradeço a
atenção dispensada ,<br><br>kleber
<br>______________________________<u></u>_________________<br>Cascavel-pm
mailing list<br><a href="mailto:Cascavel-pm@pm.org" target="_blank">Cascavel-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/<u></u>listinfo/cascavel-pm</a><br></blockquote></div></div>
</div></div><p>
</p><hr><span class="">
_______________________________________________<br>Cascavel-pm mailing
list<br><a href="mailto:Cascavel-pm@pm.org" target="_blank">Cascavel-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a></span><p></p></div></div></div></div>
<br>_______________________________________________<br>
Cascavel-pm mailing list<br>
<a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br></blockquote></div></div>