Re: How to store keys generated from Crypt::RSA module??

[Kurt Hansen]

arnab wrote:

Hi All,

 I'm using Crypt::RSA module for generating public & private keys. Now the
problem is that when I'm storing the keys in the database, and again
bringing them to do the signature or verification the Crypt::RSA module is
unable to understand the key format. I'm storing the keys in the Varchar
field of the MySQL. 


Could any body tell me when storing the keys in the databases what would be
the type of the field or how to work with the keys??

Try the "blob" type. I think varchar is too short to store the private key in a format 
Crypt:RSA expects. We store the keys in files, but store the encrypted data in "blob" 
records.

Take care,

Kurt
[EMAIL PROTECTED]

Re: Re: Re: Process exists - Segmentation fault

[abhishek jain]

Hi Its me again,
But still the things are not working right.
I tried to recompile Embperl and put PerlModule Embperl after LoadModule
embperl_module ..

Now i do not remember it was before or now but after i uncomment the
'PerlModule Embperl' line and things stop working i do not receieve
$r=shift; variable i mean $r = undef here.
Is it due to something i did during installation of embperl.
Also If i uncomment the line 'MaxRequestsPerChild 1' and comment 'PerlModule
Embperl ' then i recveive this line in error log
[Sun Jan 06 18:44:11 2008] [notice] child pid 30280 exit signal Segmentation
fault (11)

(May be error and page refreshes itself i mean the code produces output.)

and page appears , sometimes the same error appears twice and page does not
appears.

I am not sure have this error been encountered by someone else but things
are not working right for me . Also if someone wants i can mail the Embperl
logs to someone individually, i do not want to make the logs public.
Pl help. I am working on the site http://delhi.pm.org/ it is the delhi perl
mongers site and people in this group have limited knowledge of embperl but
this will push up the embperl in Delhi .
--
Thanks
Abhishek jain


On 1/4/08, Gerald Richter - ECOS GmbH <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Not sure if it makes any difference, but the lines
>
> LoadModule  embperl_module
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Embperl/Embp
> erl.so
> PerlModule Apache::DBI
> PerlModule Embperl
>
> Should be outside of the VirtualHost block (they are global anyway)
>
> The other thing that you should make sure, is that mod_perl is compiled
> with the same Perl that Embperl is and both are using modules from the
> path /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
>
> If there is any version mismatch, things cannot run correctly.
>
> Gerald
>
>
> > -Original Message-
> > From: abhishek jain [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, January 03, 2008 8:20 PM
> > To: Gerald Richter
> > Cc: modperl@perl.apache.org
> > Subject: Re: Re: Process exists - Segmentation fault
> >
> > Hi,
> > Adding PerlModule Embperl did not solved the problem , infact
> > it aggreviated it. With this the page is not didsplaye at all.
> > My apache configuration is:
> >
> > :80>
> > SuexecUserGroup "#" "#"
> > ServerName x
> > ServerAlias www.x
> > DocumentRoot 
> > ErrorLog /logs/error_log
> > CustomLog /logs/access_log combined
> > LoadModule  embperl_module
> > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Em
> bperl/Embperl.so
> > PerlModule Apache::DBI
> > PerlModule Embperl
> > >
> > Options Indexes IncludesNOEXEC FollowSymLinks
> > allow from all
> > AllowOverride All
> >
> > $">
> > SetHandler  perl-script
> > PerlHandler Embperl::Object
> > Options ExecCGI
> > 
> >  
> > Order allow,deny
> > Deny From all
> > 
> >  
> > Order allow,deny
> > Deny From all
> > 
> >
> >
> > 
> > >
> > allow from all
> > 
> > PerlSetEnv EMBPERL_ESCMODE 0
> > PerlSetEnv EMBPERL_OPTIONS 16
> > PerlSetEnv EMBPERL_MAILHOST 
> > PerlSetEnv EMBPERL_OBJECT_BASE _base.epl
> > PerlSetEnv EMBPERL_OBJECT_FALLBACK notfound.html
> > PerlSetEnv EMBPERL_DEBUG 0
> > PerlSetEnv EMBPERL_OBJECT_APP epwebapp.pl
> > 
> >
> >
> > Thanks,
> > Abhishek jain
> >
> >
> > On 1/3/08, Gerald Richter - ECOS GmbH <[EMAIL PROTECTED]> wrote:
> >
> >   Please add a
> >
> >   PerlModule Embperl
> >
> >   Somewhere _after_ the LoadModule
> >
> >   Gerald
> >
> >
> >   > -Original Message-
> >   > From: abhishek jain [mailto:[EMAIL PROTECTED]
> >   > Sent: Thursday, January 03, 2008 12:53 PM
> >   > To: Gerald Richter
> >   > Cc: modperl@perl.apache.org
> >   > Subject: Re: Process exists - Segmentation fault
> >   >
> >   > Hi,
> >   > I have the following statement in my httpd.conf
> >   >
> >   > LoadModule  embperl_module
> >   >
> > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Em
> >   > bperl/Embperl.so
> >   >
> >   > I do not have a related PerlModule just one for Apache::DBI .
> >   > Thanks,
> >   > Abhishek jain
> >   >
> >   > On 1/3/08, Gerald Richter - ECOS GmbH <
> > [EMAIL PROTECTED]  > wrote:
> >   >
> >   >   Hi,
> >   >
> >   >   Apache with mod_perl will always have this size or even
> >   > more. This is
> >   >   ok.
> >   >
> >   >   ulimit -a shows the process limits, but should normaly
> >   > not a problem
> >   >
> >   >   The behaviour you describe occurs when you do _not_

Re: Theory and practice of mod_perl win32

[Foo JH]

Thinking from the perspective of the developer who tries very hard to 
avoid dealing with C/C++, can the ApacheLounge patches and compilation 
do the trick?


Caveat: have not read the dialog on the mailing list described.

William A. Rowe, Jr. wrote:

Anyone following the dialog on [EMAIL PROTECTED] and [EMAIL PROTECTED] is 
already
aware of problems users are hitting with httpd 2.2.7 and modperl.

Here's my current theory in search of a sanity check.

There are two general classes of 'major issues' that we are going to
encounter with msvc interop between httpd, perl and modperl.

  * malloc'ator flaws; memory allocated in one components heap and
later freed in another

  * stdio/posix io handles.  These don't map between one and another.

To solve the first issue, there is only one solution.  Because perl
and modperl are both managing perl memory allocate/free, those must
be compiled against the same msvc lib.  That means using perl's
compile hinting.  In practice, this may be the difference between
a user who says "yup, works for me" and those who fail utterly.
Likewise they should use an openssl etc which are compiled against
perl's choice, or that blows up for certain openssl-oriented xs's
which have the same tight integration.

To solve the second issue, I think we can hack it.

What if modperl verified, and reinitialized if necessary, the stdio
handles associated with "its msvcrt" during the register_hooks phase
and again during the open_logs hook (run as 'very last').  This should
ensure the stdio handles are legit even if httpd started under one
msvcr, while perl and modperl are running under another.

Just a thought, I have a bunch on my plate but I wanted to float a
possible solution.

Bill

Re: Theory and practice of mod_perl win32

[William A. Rowe, Jr.]

Foo JH wrote:
Thinking from the perspective of the developer who tries very hard to 
avoid dealing with C/C++, can the ApacheLounge patches and compilation 
do the trick?


Your question is irrelevant.  Reread the post.


Caveat: have not read the dialog on the mailing list described.


Might be a good idea first.

It's essential underlying issues, not a matter for how someone builds
httpd, unless httpd is build against MSVCRT.DLL (which the ASF is doing,
but most VS 2005 users aren't.)

My point was (if you reread the post) that if modperl is built in the
same way as *perl*, and some minor code changes are made with respect
to how perl creates a MSVCR## perl-friendly environment, some of these
unavoidable issues might be avoided ;-)

If httpd | modperl is the demarcation, then the various ways that
modperl directly manipulates perl internals (and how xs extentions
interact with perl internals) aren't an issue, and for the most part
there should not these sorts of issues between modperl and httpd if
we do get that demarcation right.

Bill

APR::SockAddr

[Axel Huizinga]

Hi,

Suddenly on of my mod_perl handlers is broken with the following error:

Can't locate object method "ip_get" via package "APR::SockAddr"

at line:
my $ip = $self->{r}->connection->remote_addr->ip_get;

(temporary replaced by  $ENV{'REMOTE_ADDR'} - now the handler works again)

I didn't change the code before the error appeared - can the 
configuration cause this behavior?


Axel

Re: APR::SockAddr

[Philippe M. Chiasson]

Axel Huizinga wrote:

Hi,

Suddenly on of my mod_perl handlers is broken with the following error:

Can't locate object method "ip_get" via package "APR::SockAddr"

at line:
my $ip = $self->{r}->connection->remote_addr->ip_get;

(temporary replaced by  $ENV{'REMOTE_ADDR'} - now the handler works again)

I didn't change the code before the error appeared - can the 
configuration cause this behavior?


Missing:

use APR::SockAddr ();

somewhere ?

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/   m/gozer\@(apache|cpan|ectoplasm)\.org/



signature.asc
Description: OpenPGP digital signature