Re: cgi-lib.pl

2001-07-25 Thread John Buwa


 Hi there,

Thanks everyone for the great information you have provided. I have taken
everyones advice and installed CGI.pm with the cgi-lib compat mode on.

I am still having an issue that is only associated with the mod_perl version
of the web server?

I have two variables at initial login $userid and $password that are
populated via the cgi-lib readparse. Upon initial login the variable will
contain the correct information. If i would hit refresh they double and keep
going everytime i hit refresh?

Ex: $user = joe | Refresh -> $user=joejoe | Refresh -> $user=joejoejoe

I dont get it, i went thru my code and cleaned it up to make sure the
vairable were emptied on every execution by placing:

$userid = "";
$password = "";

before the data assignments. And still get the same effect? Anyone have a
clue, is it CGI.pm or mod_perl, the same source does not do it on a
non-mod_perl server.

Thanks,
john

> > "John" == John Buwa <[EMAIL PROTECTED]> writes:
>
> John> I have a huge system i wrote using the cgi-lib.pl as its core. I
> John> attempted to integrate mod-perl with my system and all my
> John> cgi-lib.pl which are used via a require in all scripts returns
> John> errors. My dont work, if they do the act very strange and
> John> unacceptable.
>
> John> My question is how do i use cgi-lib.pl and mod-perl together? Is
> John> anyone doing this? How can it be done.
>
> John> Here is a common error in my log:
>
> John> [Mon Jul 23 05:38:06 2001] [error] Undefined subroutine
> John>
&Apache::ROOTwww_2emy_2ddomain_2ecom::cgi_2dbin::pads::welcome_2epl::ReadPar
> John> se called at /driveb/usr/web/webroot/cgi-bin/pads/welcome.pl line 7.
>
> In addition to all the other things said in this thread, the reason
> you get this error is because cgi-lib.pl doesn't have "package", so it
> "exports" to the current package.  Unfortunately, if two
> Apache::Registry "scripts" both "require" it, then it gets defined in
> one package, but the require gets skipped in the other.  Definitely
> you need something that understands "import", such as CGI.pm's cgi-lib
> compatibility mode.
>
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!
>





Re: Help required on compile

2001-07-25 Thread Randy Kobes

On Wed, 25 Jul 2001, Murugan K wrote:

> Hai
> I am trying to build Mod-perl_1.26  on Windows NT.  For that i
> installed perl5.6.1 and apache 1.3.19 on my windows machine ( "C" drive).
> After that  (as per read me ) , i have to run  the makefile.pl .
> But that is giving the following error.
>
> Perl makefile.pl
>
> Checking if your kit is complete...
> Looks good
> Unable to find a perl 5 (by these names:
> C:\Perl\5.6.1\bin\MSWin32-x86\perl.exe
> miniperl perl perl5 perl5.6.1, in these dirs:
[ ... ]

Assuming Perl is in your PATH, do you have the same problem
building other modules? If not, try building again
within a clean source tree. If this is a general problem, try
editing your ExtUtils\MM_Win32.pm file - search for the string
"Unable to find". It's probably the backticks in the vicinity
that's causing this.

best regards,
randy kobes




Help required on compile

2001-07-25 Thread Murugan K

Hai
I am trying to build Mod-perl_1.26  on Windows NT.  For that i  installed 
perl5.6.1 and apache 1.3.19 on my windows machine ( "C" drive).
After that  (as per read me ) , i have to run  the makefile.pl . But that is giving 
the following error.

Perl makefile.pl

Checking if your kit is complete...
Looks good
Unable to find a perl 5 (by these names: C:\Perl\5.6.1\bin\MSWin32-x86\perl.exe 
miniperl perl perl5 perl5.6.1, in these dirs:
 D:\Program Files\DevStudio\SharedIDE\BIN
 D:\Program Files\DevStudio\VC\BIN D:\Program Files\DevStudio\VC\BIN\WINNT 
c:\perl\5.6.1\bin\mswin32-x86 E:\DevStudio\VC\BIN E:\DevStudio\VC\BIN\WINNT
 c:\perl\5.6.1\bin\MSWin32-x86)

Writing Makefile for Apache
Writing Makefile for Apache::Connection
Writing Makefile for Apache::Constants
Writing Makefile for Apache::File
Writing Makefile for Apache::Leak
Writing Makefile for Apache::Log
Writing Makefile for Apache::ModuleConfig
Writing Makefile for Apache::PerlRunXS
Writing Makefile for Apache::Server
Writing Makefile for Apache::Symbol
Writing Makefile for Apache::Table
Writing Makefile for Apache::URI
Writing Makefile for Apache::Util
Writing Makefile for mod_perl


After that , if i try the nmake install - it is giving the following error

cp lib/Apache/Registry.pm blib\lib\Apache\Registry.pm
cp lib/Apache/SizeLimit.pm blib\lib\Apache\SizeLimit.pm
cp lib/Apache/Resource.pm blib\lib\Apache\Resource.pm
cp lib/Apache/PerlSections.pm blib\lib\Apache\PerlSections.pm
cp lib/Apache/RegistryNG.pm blib\lib\Apache\RegistryNG.pm
cp lib/Apache/PerlRun.pm blib\lib\Apache\PerlRun.pm
cp lib/Apache/Debug.pm blib\lib\Apache\Debug.pm
cp lib/mod_perl_hooks.pm.PL blib\lib\mod_perl_hooks.pm.PL
cp lib/Apache/MyConfig.pm blib\lib\Apache\MyConfig.pm
cp mod_perl_tuning.pod blib\lib\mod_perl_tuning.pod
cp lib/Apache/ExtUtils.pm blib\lib\Apache\ExtUtils.pm
cp lib/Apache/httpd_conf.pm blib\lib\Apache\httpd_conf.pm
cp lib/Apache/SIG.pm blib\lib\Apache\SIG.pm
cp mod_perl_traps.pod blib\lib\mod_perl_traps.pod
cp lib/Apache/src.pm blib\lib\Apache\src.pm
cp lib/Apache/Options.pm blib\lib\Apache\Options.pm
cp lib/mod_perl.pm blib\lib\mod_perl.pm
cp lib/mod_perl_hooks.pm blib\lib\mod_perl_hooks.pm
cp mod_perl_cvs.pod blib\lib\mod_perl_cvs.pod
cp cgi_to_mod_perl.pod blib\lib\cgi_to_mod_perl.pod
cp lib/Apache/Symdump.pm blib\lib\Apache\Symdump.pm
cp lib/Apache/Opcode.pm blib\lib\Apache\Opcode.pm
cp lib/Apache/Apache.pm blib\lib\Apache\Apache.pm
cp lib/Apache/Status.pm blib\lib\Apache\Status.pm
cp lib/Apache/RedirectLogFix.pm blib\lib\Apache\RedirectLogFix.pm
cp lib/Apache/Include.pm blib\lib\Apache\Include.pm
cp mod_perl_method_handlers.pod blib\lib\mod_perl_method_handlers.pod
cp lib/Apache/RegistryBB.pm blib\lib\Apache\RegistryBB.pm
cp lib/Apache/StatINC.pm blib\lib\Apache\StatINC.pm
cp lib/Apache/RegistryLoader.pm blib\lib\Apache\RegistryLoader.pm
cp lib/Apache/test.pm blib\lib\Apache\test.pm
cp lib/Apache/FakeRequest.pm blib\lib\Apache\FakeRequest.pm
cp lib/Apache/Constants/Exports.pm blib\lib\Apache\Constants\Exports.pm
cp mod_perl.pod blib\lib\mod_perl.pod
cp lib/Bundle/Apache.pm blib\lib\Bundle\Apache.pm

The name specified is not recognized as an
internal or external command, operable program or batch file.
NMAKE : fatal error U1077: '..\0' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

Note: 
   I am not using active perl for this purpose. i downloaded from the CPAN , built and 
installed.  Here by attached the makefile created by makefile.pl for your reference

Thanks in advance

Expecting your help

Regards
K.Murugan



 Makefile


Re: ODBC for Apache

2001-07-25 Thread Joshua Chamas

"Castellon, Francisco" wrote:
> 
> Hi I am running on Windows98SE, Apache 1.20, mod_perl 1.25, php 4.0.6, and
> have the latest Apache::ASP installed and have Activestate's Perl installed
> (build 626).
> 
> I want to be able to access, Oracle, SQL and MSAccess databases as well as a
> couple of other Databases that support ODBC. I want to access these DBs from
> my apache server. What do i need??
> 

DBD::ODBC is your ticket, running under DBI 
  http://dbi.symbolstone.org/

You can probably install DBD::ODBC for Activestate perl with 
the ppm installer, as they will likely already have compiled
it for you.  Apache::DBI is installed with CPAN.

--Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Gunther Birznieks

At 01:19 AM 7/26/2001 +0200, Issac Goldstand wrote:
[snipped]

>I see what you mean.  I'm not dealing with client certs (yet), and I'm
>thinking that when the system that I'm testing now goes production, it'll be
>a front-end SSL, back-end non-SSL sorta deal...  But that won't work for now
>due to other security issues on the developments boxes...

[snipped]


>I understand that.  It's just not doable for this...  In actuality, the
>"back-end" server now is not REALLY back-end... The mod_perl server is
>_behind_ that, so I'm really doing what you're suggesting already :)
>
>However, information must still get to this "middle-level" server, and the
>top level server certainly can't be trusted to decode sensitive
>information...

Considering this issue, it seems that what might help you more is a VPN. 
Have you tried using SSH port forwarding for the time being? And just allow 
the SSL stuff to go from your external web server directly through an SSH 
vpn link to the back-end (your true front end) server.

Later,
 Gunther






Help needed with compile

2001-07-25 Thread Bryan Coon

Hi, I am trying to compile Apache with a bunch of modules and DSO.  I cant
find any documentation that covers all of this though.
perl.apache.org/guide/ give lots of combination examples, but not all.

I would like to build Apache 1.3.20 with mod_ssl, mod_perl, mod_php and DSO
support, and for apache, --prefix=/apachessl.

Can anyone give me either a site that has explicit instructions on how to do
this?  Or maybe an example?

Thanks!
Bryan



Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Issac Goldstand

> > > The front end server must be configured to understand SSL. Otherwise,
how
> > > else can the HTTP request be pulled apart (decrypted) to understand
that
> >it
> > > has to be forwarded to the backend server.
> >
> >2 words: dumb proxy.  The request doesn't need to be pulled apart by the
> >front-end server in this case.  The entire virtualhost is supposed to be
> >tunneled directly to the back-end server.  That's what I'm trying to
figure
> >out how to do...
>
> I see. I don't know if that will work. The connect header is a special
> proxy feature to allow a proxy to just pass through all the TCP level
> packets instead of opening a separate SSL client connection. But from a
> reverse proxy perspective, I am not sure that mod_proxy is automatically
> given this special header by the browser as it might if you configured IE
> or Netscape to use a physical proxy server.
>
> But it definitely won't work based on the HTTP Hostname parameter because
> SSL has to be established before any other HTTP header other than the
weird
> connect one is decoded.

I know :(

> > > If you configure the back-end server to understand SSL, that's OK, but
> > > beware that all mod_proxy is doing is establishing one SSL connection
from
> > > browser to mod_proxy and then a brand new SSL connection from
mod_proxy to
> > > the backend server. 2 separate SSL sessions because SSL cannot (ie
> > > inconvenient to) be man-in-the-middled.
> >
> >I know that. The key is (and must be) on the back-end server.  Which is
why
> >I'm trying to do it this way.  The mod_perl book seemed to imply that
this
> >was possible, and I _know_ that mod_proxy is supposed to recognize
CONNECT
> >requests for this very purpose - it says so in the manual...  I just
don't
> >know how to set it up properly...
> >
> > > It has some likelihood to also to be inefficient because I am not
entirely
> > > sure that mod_proxy is caching the SSL client session key that it
> >generates
> > > to connect to the back-end server as the browser normally does for the
> > > front end.
> >
> >I'm not even sure that mod_proxy can be it's own SSL client...  The
> >documentation says it knows how to handle incoming CONNECTS, but I'm not
> >sure that it could make its own HTTPS request...
>
> If you try it, I think you will find that this works. If you compile in
> mod_ssl, mod_proxy can establish SSL connections to the back-end. The only
> thing you lose other than performance is the capability of passing a PKI
> certificate through the proxy (since decoding and establishing a new SSL
> connection would be considered a man-in-the-middle attack).

I see what you mean.  I'm not dealing with client certs (yet), and I'm
thinking that when the system that I'm testing now goes production, it'll be
a front-end SSL, back-end non-SSL sorta deal...  But that won't work for now
due to other security issues on the developments boxes...

> When you don't care about client certificates, it really doesn't matter
> that the reverse proxy is in the middle because the reverse proxy has the
> valid server certificate that your client is pre-programmed to understand
> is a valid certificate (eg from Verisign).
>
> Really, the cleanest way of doing what you want is to run the SSL engine
on
> the front-end and then proxy (convert) back the connection to the backend
> as HTTP. If you are using some authentication on the front-end (eg client
> certificates) there are modules which will allow you to take a USER_DN and
> pass it to the back-end server as an addition parameter (eg using
> mod_rewrite) or as another custom HTTP header.

I understand that.  It's just not doable for this...  In actuality, the
"back-end" server now is not REALLY back-end... The mod_perl server is
_behind_ that, so I'm really doing what you're suggesting already :)

However, information must still get to this "middle-level" server, and the
top level server certainly can't be trusted to decode sensitive
information...

  Issac

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B




Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Gunther Birznieks

At 07:05 PM 7/25/2001 +0200, Issac Goldstand wrote:

> > The front end server must be configured to understand SSL. Otherwise, how
> > else can the HTTP request be pulled apart (decrypted) to understand that
>it
> > has to be forwarded to the backend server.
>
>2 words: dumb proxy.  The request doesn't need to be pulled apart by the
>front-end server in this case.  The entire virtualhost is supposed to be
>tunneled directly to the back-end server.  That's what I'm trying to figure
>out how to do...

I see. I don't know if that will work. The connect header is a special 
proxy feature to allow a proxy to just pass through all the TCP level 
packets instead of opening a separate SSL client connection. But from a 
reverse proxy perspective, I am not sure that mod_proxy is automatically 
given this special header by the browser as it might if you configured IE 
or Netscape to use a physical proxy server.

But it definitely won't work based on the HTTP Hostname parameter because 
SSL has to be established before any other HTTP header other than the weird 
connect one is decoded.

> > If you configure the back-end server to understand SSL, that's OK, but
> > beware that all mod_proxy is doing is establishing one SSL connection from
> > browser to mod_proxy and then a brand new SSL connection from mod_proxy to
> > the backend server. 2 separate SSL sessions because SSL cannot (ie
> > inconvenient to) be man-in-the-middled.
>
>I know that. The key is (and must be) on the back-end server.  Which is why
>I'm trying to do it this way.  The mod_perl book seemed to imply that this
>was possible, and I _know_ that mod_proxy is supposed to recognize CONNECT
>requests for this very purpose - it says so in the manual...  I just don't
>know how to set it up properly...
>
> > It has some likelihood to also to be inefficient because I am not entirely
> > sure that mod_proxy is caching the SSL client session key that it
>generates
> > to connect to the back-end server as the browser normally does for the
> > front end.
>
>I'm not even sure that mod_proxy can be it's own SSL client...  The
>documentation says it knows how to handle incoming CONNECTS, but I'm not
>sure that it could make its own HTTPS request...

If you try it, I think you will find that this works. If you compile in 
mod_ssl, mod_proxy can establish SSL connections to the back-end. The only 
thing you lose other than performance is the capability of passing a PKI 
certificate through the proxy (since decoding and establishing a new SSL 
connection would be considered a man-in-the-middle attack).

When you don't care about client certificates, it really doesn't matter 
that the reverse proxy is in the middle because the reverse proxy has the 
valid server certificate that your client is pre-programmed to understand 
is a valid certificate (eg from Verisign).

Really, the cleanest way of doing what you want is to run the SSL engine on 
the front-end and then proxy (convert) back the connection to the backend 
as HTTP. If you are using some authentication on the front-end (eg client 
certificates) there are modules which will allow you to take a USER_DN and 
pass it to the back-end server as an addition parameter (eg using 
mod_rewrite) or as another custom HTTP header.

>   Issac
>
> > At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote:
> > >I am trying to make a back-end mod_perl/mod_ssl server.  The front-end
> > >server that is currently in place is doing a great job forwarding normal
> > >requests to the back-end, but it is not forwarding SSL.  Now, the
>front-end
> > >server does not understand SSL, itself.  What I'm doing is trying to
>force
> > >the entire VirtualHost listening on port 443 to an IP on a private subnet
>on
> > >an obscure port (what I do for all the back-end servers.  There are
>actually
> > >3 of them doing various things).  But it won't work.  The strange thing
>is
> > >that if I go to http://mysite:443/ I get the default Apache "It Worked"
> > >page, but https://mysite/ generates an error saying that the front end
> > >cannot understand, which seems to be pointing at the fact that it's not
> > >forwarding ANYTHING to the back-end server...
> > >
> > >Stas & Eric: This situation is mentioned in your book, but in nowhere
>enough
> > >detail.  IMHO, that segment of the book (near the end of chapter "Server
> > >Setup Strategies for the Best Performance") should be redone in better
> > >detail to explain forwarding SSL to the back-end server.
> > >
> > >   Issac
> > >
> > >Internet is a wonderful mechanism for making a fool of
> > >yourself in front of a very large audience.
> > >   --Anonymous
> > >
> > >Moving the mouse won't get you into trouble...  Clicking it might.
> > >   --Anonymous
> > >
> > >PGP Key 0xE0FA561B - Fingerprint:
> > >7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
> >
> > __
> > Gunther Birznieks ([EMAIL PROTECTED])
> > eXtropia - The Open Web Technology Company
> > ht

Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Issac Goldstand


> The front end server must be configured to understand SSL. Otherwise, how
> else can the HTTP request be pulled apart (decrypted) to understand that
it
> has to be forwarded to the backend server.

2 words: dumb proxy.  The request doesn't need to be pulled apart by the
front-end server in this case.  The entire virtualhost is supposed to be
tunneled directly to the back-end server.  That's what I'm trying to figure
out how to do...

> If you configure the back-end server to understand SSL, that's OK, but
> beware that all mod_proxy is doing is establishing one SSL connection from
> browser to mod_proxy and then a brand new SSL connection from mod_proxy to
> the backend server. 2 separate SSL sessions because SSL cannot (ie
> inconvenient to) be man-in-the-middled.

I know that. The key is (and must be) on the back-end server.  Which is why
I'm trying to do it this way.  The mod_perl book seemed to imply that this
was possible, and I _know_ that mod_proxy is supposed to recognize CONNECT
requests for this very purpose - it says so in the manual...  I just don't
know how to set it up properly...

> It has some likelihood to also to be inefficient because I am not entirely
> sure that mod_proxy is caching the SSL client session key that it
generates
> to connect to the back-end server as the browser normally does for the
> front end.

I'm not even sure that mod_proxy can be it's own SSL client...  The
documentation says it knows how to handle incoming CONNECTS, but I'm not
sure that it could make its own HTTPS request...

  Issac

> At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote:
> >I am trying to make a back-end mod_perl/mod_ssl server.  The front-end
> >server that is currently in place is doing a great job forwarding normal
> >requests to the back-end, but it is not forwarding SSL.  Now, the
front-end
> >server does not understand SSL, itself.  What I'm doing is trying to
force
> >the entire VirtualHost listening on port 443 to an IP on a private subnet
on
> >an obscure port (what I do for all the back-end servers.  There are
actually
> >3 of them doing various things).  But it won't work.  The strange thing
is
> >that if I go to http://mysite:443/ I get the default Apache "It Worked"
> >page, but https://mysite/ generates an error saying that the front end
> >cannot understand, which seems to be pointing at the fact that it's not
> >forwarding ANYTHING to the back-end server...
> >
> >Stas & Eric: This situation is mentioned in your book, but in nowhere
enough
> >detail.  IMHO, that segment of the book (near the end of chapter "Server
> >Setup Strategies for the Best Performance") should be redone in better
> >detail to explain forwarding SSL to the back-end server.
> >
> >   Issac
> >
> >Internet is a wonderful mechanism for making a fool of
> >yourself in front of a very large audience.
> >   --Anonymous
> >
> >Moving the mouse won't get you into trouble...  Clicking it might.
> >   --Anonymous
> >
> >PGP Key 0xE0FA561B - Fingerprint:
> >7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
>
> __
> Gunther Birznieks ([EMAIL PROTECTED])
> eXtropia - The Open Web Technology Company
> http://www.eXtropia.com/
>




Re: Setup help needed

2001-07-25 Thread Ged Haywood

Hi there,

On Tue, 24 Jul 2001, Bryan Coon wrote:

> Hi, I am having trouble figuring out what is up with mod_perl.
> 
> I currently have apache 1.3.20 running on RH6.2, compiled with mod_ssl, mm
> 1.1.3 and DSO support enabled.
> 
> What is the method to install mod_perl?

http://perl.apache.org/guide

73,
Ged.




Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Gunther Birznieks

The front end server must be configured to understand SSL. Otherwise, how 
else can the HTTP request be pulled apart (decrypted) to understand that it 
has to be forwarded to the backend server.

If you configure the back-end server to understand SSL, that's OK, but 
beware that all mod_proxy is doing is establishing one SSL connection from 
browser to mod_proxy and then a brand new SSL connection from mod_proxy to 
the backend server. 2 separate SSL sessions because SSL cannot (ie 
inconvenient to) be man-in-the-middled.

It has some likelihood to also to be inefficient because I am not entirely 
sure that mod_proxy is caching the SSL client session key that it generates 
to connect to the back-end server as the browser normally does for the 
front end.

At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote:
>I am trying to make a back-end mod_perl/mod_ssl server.  The front-end
>server that is currently in place is doing a great job forwarding normal
>requests to the back-end, but it is not forwarding SSL.  Now, the front-end
>server does not understand SSL, itself.  What I'm doing is trying to force
>the entire VirtualHost listening on port 443 to an IP on a private subnet on
>an obscure port (what I do for all the back-end servers.  There are actually
>3 of them doing various things).  But it won't work.  The strange thing is
>that if I go to http://mysite:443/ I get the default Apache "It Worked"
>page, but https://mysite/ generates an error saying that the front end
>cannot understand, which seems to be pointing at the fact that it's not
>forwarding ANYTHING to the back-end server...
>
>Stas & Eric: This situation is mentioned in your book, but in nowhere enough
>detail.  IMHO, that segment of the book (near the end of chapter "Server
>Setup Strategies for the Best Performance") should be redone in better
>detail to explain forwarding SSL to the back-end server.
>
>   Issac
>
>Internet is a wonderful mechanism for making a fool of
>yourself in front of a very large audience.
>   --Anonymous
>
>Moving the mouse won't get you into trouble...  Clicking it might.
>   --Anonymous
>
>PGP Key 0xE0FA561B - Fingerprint:
>7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/




[OT] Using mod_proxy and mod_ssl to forward SSL connections

2001-07-25 Thread Issac Goldstand

I am trying to make a back-end mod_perl/mod_ssl server.  The front-end
server that is currently in place is doing a great job forwarding normal
requests to the back-end, but it is not forwarding SSL.  Now, the front-end
server does not understand SSL, itself.  What I'm doing is trying to force
the entire VirtualHost listening on port 443 to an IP on a private subnet on
an obscure port (what I do for all the back-end servers.  There are actually
3 of them doing various things).  But it won't work.  The strange thing is
that if I go to http://mysite:443/ I get the default Apache "It Worked"
page, but https://mysite/ generates an error saying that the front end
cannot understand, which seems to be pointing at the fact that it's not
forwarding ANYTHING to the back-end server...

Stas & Eric: This situation is mentioned in your book, but in nowhere enough
detail.  IMHO, that segment of the book (near the end of chapter "Server
Setup Strategies for the Best Performance") should be redone in better
detail to explain forwarding SSL to the back-end server.

  Issac

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B








Re: Child Interprocess Data

2001-07-25 Thread Nouguier Olivier

Kevin Schroeder wrote:

> Hi,I want to create a program for mod_perl that shares information
> in between all the child processes so they all have current
> information.  The data will be stored in a MySQL database, but rather
> than query the DB each time which, due to the kind of server load,
> would work but would be somewhat needless, I would like to have a
> certain amount of data stored within the server and accessable to all
> the Apache processes. Could someone point me in the right
> direction to start? Kevin

Hi,
IPC::ShareLite is your friend

--
My mother always used to tell me, "The early bird gets the worm."
The message seemed pretty clear to me: If you sleep late, you're
a lot less likely to be killed by a bird.
-- Elliott Downing






Re: startup.pl for configuration

2001-07-25 Thread Dominique Quatravaux

  Hello,

> I would like to have a config file like /etc/mywebapp.conf where I would
> put all my modules configuration.

  Yep, that's what we do too.

>  Then I would have a WebApp::LoadConfig
> module that would run from startup.pl, and initialize my Perl modules
> default variables at Apache start.

  I'd rather think of it as a WebApp::Config _object class_ than a
WebApp::LoadConfig _module_ (see below).

> My config file would be some like :
> 
> ### /etc/mywebapp.conf
> ###
> ###
> MyPackageOne::Default_Value_One = 1
> MyPackageOne::Default_Value_One = 2

How about the Config::Ini module from CPAN, that implements m/Win...s/
.INI format ? It's versatile and quite easy to understand even for
your newbie users. Plus it's already done and well tested, and it has
write support (comments are discarded). Here at IDEALX we use a
subclass that goes like this:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

package My::Hierarchy::Config;

use strict;

use Config::Ini;

use vars qw(@ISA); @ISA=qw(Config::Ini);

# new My::Hierarchy::Config() called with no args returns a
# config opened on the default configuration file.
sub new {
my ($class,$filename)=@_;
return $class->SUPER::new($filename or '/etc/mywebapp.conf');
}

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

And then in every script:

my $config=new My::Hierarchy::Config;

$config->get(['somesection','somekey']);


This allows for maximum flexibility: by adding code to
My::Hierarchy::Config, you can provide convenience functions to do
just about anything that suits your needs (e.g. there could be one to
export the whole config file to random variables in all packages).

> 
> and my startup.pl would have :
> 
> ### startup.pl
> WebApp::LoadConfig->run("/etc/mywebapp.conf")
> [...]
> Would this be a good idea ? What do you think about? does somebody
> already use it ?

Well, it depends. We find it quite useful to stay in the CGI context
for our scripts, since unit tests are much easier with CGI.pm's
debugging code. And for that reason, we choose not to specialize
mod_perl's environment more than it already is (e.g. $r et al.). We
put the above boilerplate in every script, perhaps wrapped in a
convenience function (e.g. ``use My::Hierarchy::CGI;''). But if you
intend to jump the gap and have a totally ad-hoc structure for your
Perl pages (e.g. you use HTML::Mason or something alike), then yes,
why not make $config a global variable accessible to all Perl WWW
pages ?

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

Dominique Quatravaux <[EMAIL PROTECTED]>



Re: Increasing Shared Memory

2001-07-25 Thread perrin

Quoting Bob Foster <[EMAIL PROTECTED]>:
> Immediately
> after I make an Oracle database connection, the child jumps from a size
> of
> 3.6M (2.4M shared) to 17.4M (3.4M shared).  The child process slowly
> grows
> to 22.2M (3.4M shared).  The loaded libs Sizes total 13.6M.
> 
> Shouldn't the libs load into shared memory?  If so, how?

DBI->install_driver()

See http://perl.apache.org/guide/performance.html#Initializing_DBI_pm for more.

- Perrin