Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: Thanks for your prompt response! We did compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 but we're trying to move away from this now, because of vendors like IBM and Oracle not willing to re-compile (websphere mods and mod_ossos) with the same flags. Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. Like I said before Doug MacEachern actually allows you to get away with this in mod_perl 1.27 (with mod_perl 1.24 it would squeal and terminate during compile time). Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. Is there another low level consideration I'm not taking into account? Everything will work OK if all the components are compiled without large file support. Of course you won't be able to handle files 2GB. Last but not least...Perl 5.6.1 and greater compiles with LFS (default) and Apache has always compiled without it (unless you specifically specify it). Did you re-compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64? mod_perl 1.x does it for you (i.e. uses perl's cppflags) if you build static (since it builds apache). perl -V:cppflags cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/include/gdbm'; I'm not sure what happen if you build DSO. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Guys Everything you've said so far make complete sense (thanks for that!). My question now is, did Doug take this into consideration when he build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) and somehow wrote a function that cleans up the data structures from perl? I think I need someone with 'inside information' into mod_perl to comment on this one... Thx again, Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 14:53 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: As you can see it suggests rebuilding mod_perl with $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Thu, 19 Jun 2003 [EMAIL PROTECTED] wrote: My question now is, did Doug take this into consideration when he build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) I'm sure Doug took into consideration all sorts of things we never even thought about. Try it out and let us know what happens? I think I need someone with 'inside information' into mod_perl Well you have the source code... :) 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hey I found this link on the net and it seems to answer my question (right at the bottom), http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/uselargefiles_P3969/ Thanks to all who contributed to my query... Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 19 June 2003 14:45 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi there, On Thu, 19 Jun 2003 [EMAIL PROTECTED] wrote: My question now is, did Doug take this into consideration when he build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) I'm sure Doug took into consideration all sorts of things we never even thought about. Try it out and let us know what happens? I think I need someone with 'inside information' into mod_perl Well you have the source code... :) 73, Ged. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Regards, Jaco Greyling -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 03:36 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) [EMAIL PROTECTED] wrote: Guys, anyone with experience on the below problem??? why reposting the same question 3 times? Please give people some time to respond to your questions, you can't expect an immediate reply. Please advice, I would really appreciate the help. [...] Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... Sounds like the right place to me. We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? You have to send a complete problem report as explained here, including a core dump's back trace: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Ah sorry then, I thought I'm concerned about Segmentation Faults meant that you had such. You can rebuild Apache with: CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Assuming that you don't trip on any functions that Apache considers unsafe on your os with largefiles enabled. See Makefile.PL for more info. The point is: You need to have both components to agree on sizeof() the vars they use. If they don't at best you will get immediate problem, at worst there will be subtle problems happening only in certain situations. It may work OK, if you call only methods which use variables, whose sizeof() doesn't change when LARGE_FILES are enabled. I know it's a big pain :( Same in mod_perl 2.0 and Apache 2.0. e.g. we have a problem with APR::PerlIO, and it seems that I've worked around it, by disabling -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 only for building this module, if perl was built with large files support. Your safest bet is to have both components compiled with the same large file flags. Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Understood. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Thanks for your prompt response! We did compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 but we're trying to move away from this now, because of vendors like IBM and Oracle not willing to re-compile (websphere mods and mod_ossos) with the same flags. Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. Like I said before Doug MacEachern actually allows you to get away with this in mod_perl 1.27 (with mod_perl 1.24 it would squeal and terminate during compile time). Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. Is there another low level consideration I'm not taking into account? Last but not least...Perl 5.6.1 and greater compiles with LFS (default) and Apache has always compiled without it (unless you specifically specify it). Did you re-compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64? Thanks again, Jaco Greyling -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 10:59 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) [EMAIL PROTECTED] wrote: Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Ah sorry then, I thought I'm concerned about Segmentation Faults meant that you had such. You can rebuild Apache with: CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Assuming that you don't trip on any functions that Apache considers unsafe on your os with largefiles enabled. See Makefile.PL for more info. The point is: You need to have both components to agree on sizeof() the vars they use. If they don't at best you will get immediate problem, at worst there will be subtle problems happening only in certain situations. It may work OK, if you call only methods which use variables, whose sizeof() doesn't change when LARGE_FILES are enabled. I know it's a big pain :( Same in mod_perl 2.0 and Apache 2.0. e.g. we have a problem with APR::PerlIO, and it seems that I've worked around it, by disabling -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 only for building this module, if perl was built with large files support. Your safest bet is to have both components compiled with the same large file flags. Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Understood. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. I really don't see why you don't recompile your Perl. It's not a big deal and it's going to be a lot safer that way. Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. I can't tell you how much what you're proposing to do worries me. I wouldn't dream of doing it on one of my servers, not even on a development machine. The size of the files you access isn't the issue. It's the size of the variables in the C data structures. If different parts of the same code disagree about that, and they pass each other pointers to different shaped structures, you are going to have serious problems. As Stas said, the *best* you can hope for is an immediate crash of some sort. It's possibile however that the problems might not surface immediately and that the symptoms might not be obvious. You could have all kinds of data corruption before you know what's hit you. 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Ok -
This comes from the Makefile.PL:
sub uselargefiles_check {
return unless $] = 5.006 and $Config{uselargefiles}
and $PERL_USELARGEFILES and $USE_APXS;
local $Apache::src::APXS = $WITH_APXS;
my $cflags = Apache::src-new-apxs('-q' = 'CFLAGS') || '';
return if $cflags =~ /LARGEFILE/;
$PERL_USELARGEFILES=0; #just do it since
return; #nobody seems to listen to the warning below
phat_warn(EOF);
Your Perl is uselargefiles enabled, but Apache is not, suggestions:
*) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0
*) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
*) Rebuild Perl with Configure -Uuselargefiles
*) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1)
EOF
}
As you can see it suggests rebuilding mod_perl with $PERL_USELARGEFILES=0 (which we
do) so according to him it will work?
If not then I'll mail Doug and tell him to add a conditional statement :)
Jaco Greyling
-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 13:06
To: Greyling, Jaco
Cc: mod_perl Mailing List
Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there,
On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote:
Thus without re-compiling my whole Perl 5.8.0 build I need to come
up with a solution.
I really don't see why you don't recompile your Perl. It's not a big
deal and it's going to be a lot safer that way.
Sorry for my ignorance but it does look like it will work (non-LFS
Apache) provided that you don't try to access files larger then 2GB.
I can't tell you how much what you're proposing to do worries me.
I wouldn't dream of doing it on one of my servers, not even on a
development machine.
The size of the files you access isn't the issue. It's the size of
the variables in the C data structures. If different parts of the
same code disagree about that, and they pass each other pointers to
different shaped structures, you are going to have serious problems.
As Stas said, the *best* you can hope for is an immediate crash of
some sort. It's possibile however that the problems might not surface
immediately and that the symptoms might not be obvious. You could
have all kinds of data corruption before you know what's hit you.
73,
Ged.
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi, mod_perl does not look different between 2 builds (lfs and non-lfs apache) - our assumption that mod_perl shares memory with Apache might just be wrong or there is a way for mod_perl to make system calls with lfs against perl and non-lfs against apache. Hence we need a developer feedback :) Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 14:53 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: As you can see it suggests rebuilding mod_perl with $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
All Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... Regards, Jaco Greyling _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
Howto: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
All Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 make ... Regards, Jaco Greyling Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
All Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... Regards, Jaco Greyling Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: Guys, anyone with experience on the below problem??? why reposting the same question 3 times? Please give people some time to respond to your questions, you can't expect an immediate reply. Please advice, I would really appreciate the help. [...] Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... Sounds like the right place to me. We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? You have to send a complete problem report as explained here, including a core dump's back trace: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Trouble using mod_perl and IE5.x, IE6.x
Hi, I'm using Apache 1.3.26, mod_perl 1.26 and perl 5.6.1 on a HPUX 11 system. My program genarate HTML page with perl cgi. Sometimes, html pages are lost by the IE browser : Internet Explorer chooses to display the default Microsoft internal server error page instead of the generate HTML page. This HTML page is well generated but the code is in the error_log file of the http server. This trouble don't appear every time on the same page. There is no trouble with Netscape 7. Thanks in advance for your help Regards Christophe
Re: Trouble using mod_perl and IE5.x, IE6.x
Hello, I'm not generating an error page. The trouble occurs for sample with this little simple script (sometime on 1 browser using 16 browsers simultanly for sample) : print(html); sleep (5); print(head); print(titleTITRE DE LA PAGE\/title); print (META http-equiv=\PRAGMA\ content=\NO-CACHE\); print(\/head); print(body bgcolor=\red\); print (SAMPLE TROUBLE HTML PAGE); print(\/body); sleep (5); print (\/html); Thanks for your help. Christophe. Per Einar Ellefsen wrote: Hello Christophe, At 11:55 07.11.2002, simon wrote: Hi, I'm using Apache 1.3.26, mod_perl 1.26 and perl 5.6.1 on a HPUX 11 system. My program genarate HTML page with perl cgi. Sometimes, html pages are lost by the IE browser : Internet Explorer chooses to display the default Microsoft internal server error page instead of the generate HTML page. This HTML page is well generated but the code is in the error_log file of the http server. This trouble don't appear every time on the same page. There is no trouble with Netscape 7. If it is an error page you are generating (it seems like it), you have hit a known problem with IE described with a solution here: http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html#Internet_Explorer_disregards_your_ErrorDocuments -- Per Einar Ellefsen [EMAIL PROTECTED] -- Christophe SIMON EVER TEAM Knowledge Into Action Immeuble l'Aquilon - 40 b rue de la Villette 69425 LYON Cedex 03 - FRANCE Tél. : +33 (0)4 26 68 33 00 - Fax : +33 (0)4 26 68 33 16 mailto:c.simon;ever-team.com - Site Web : http://www.ever-team.com
Re: Trouble using mod_perl and IE5.x, IE6.x
Hi there, On Thu, 7 Nov 2002, simon wrote: The trouble occurs for sample with this little simple script print(html); sleep (5); print(head); Do you first send the HTTP headers somehow? 73, Ged.
RE: Trouble using mod_perl and IE5.x, IE6.x
Greetings. Now this is OT'ish but... print(titleTITRE DE LA PAGE\/title); Why are you escaping all your '/'s? There is no need to do it. Cheers, alf P.S: I strongly suspect that the sleep call and its position (what if you move it above the /body tag?) are to blame for the behavior you see (i.e. I'd bet you are triggering some timeout in IE). But that's only gut feeling.
Creating a proxy using mod_perl
I have a site that does secure credit card transactions on behalf of
merchants. As soon as a cardholder on the merchant site is ready to pay,
the merchant redirects the cardholder to my site, and I pick up payment
details from the cardholder directly over SSL.
When the cardholder is accessing my site, I retrieve certain elements
from the merchant site and present them to the cardholder while he is
completing the purchase on my site. Since the merchants do not pick up
any payment sensitive information, quite a few of them do not have SSL
certificates themselves.
Typically, when the cardholder is on my payment site, I will fetch the
company logo and various other certain elements from the merchant site.
If the merchant site does not have SSL himself, these items will be
fetched using normal http (and not https) requests. In Internet
Explorer, if you are visiting a site using https that refers to img src
links or similar from a non-ssl site (through normal http) the user will
get annoying dialog boxes warning him about this.
To avoid this situation, I allow merchants to proxy the non-SSL stuff
through my site, where they actually refer to an local url with a
parameter to where the item can be retrieved from the non-SSL site. My
script will retrieve the page from the http link and return it through a
local https link, which makes the Internet Explorer warnings go away.
The way I am currently doing this is as follows:
I have a handler module which is activated through the following in
httpd.conf:
Location /proxy
SetHandler perl-script
PerlHandler Proxy
/Location
The Proxy.pm module looks as follows:
package Proxy;
use strict;
use warnings;
use Apache::Constants qw (REDIRECT OK);
use LWP::UserAgent;
sub handler {
my $r = shift;
my $ua = new LWP::UserAgent;
$ua-timeout (30);
my $uri = $ENV{REQUEST_URI};
$uri =~ /proxy\?url=(.*)$/;
$uri = $1;
my $request = new HTTP::Request (GET = $uri);
my $response = $ua-request ($request);
if ($response-is_success) {
$r-content_type ($response-headers-header ('Content-type'));
$r-send_http_header;
print $response-content;
} else {
print $response-error_as_HTML;
}
return OK;
}
1;
In short, it takes a request such as
https://my.secure.site/proxy?url=http://from.unsecure.site/someimg.gif
and retrieves the data from the unsecure site and return it through the
secure site at my end.
This works _mostly_ ok, but on what seems like random occations the
httpd process will die (segmentation fault). I can not be sure that the
proxy module is to blame, but I log process id the access log as well
and it seems the last request to be served always seem to be such a
proxy request (my server servers other stuff as well).
Any ideas on why this is so?
Any other ways of accomplishing the same without the added overhead of
my perl module?
Thanks in advance,
Marius Kjeldahl
Re: Creating a proxy using mod_perl
Marius Kjeldahl wrote: Any other ways of accomplishing the same without the added overhead of my perl module? There was an example in the eagle-book, AFAIR, you need to build a custom PerlTranslateHandler and rewrite the filename to the url of your customer and use $r-handler(mod-proxy), (or maybe proxy or mod_proxy, just check the docs and look for the needed AddHandler directive) ciao -- Mit freundlichen Grüßen - Nico Erfurth Headlight Housingfactory GmbH Email: [EMAIL PROTECTED] -
Re: Creating a proxy using mod_perl
On Fri, 15 Mar 2002, Marius Kjeldahl wrote: Any other ways of accomplishing the same without the added overhead of my perl module? You can use 1. mod_proxy: ProxyPass /images/http://image.site/image/ 2. mod_accel: AccelPass /images/http://image.site/image/ 3. default-handler - images must be on the same host: Location /images/ SetHandler default-handler /Location Igor Sysoev
Re: Creating a proxy using mod_perl
I guess these all suffer from the fact that the parameters have to be specified in httpd.conf, which makes it impossible to pass a url to fetch from in a parameter, right? Marius K. Igor Sysoev wrote: On Fri, 15 Mar 2002, Marius Kjeldahl wrote: Any other ways of accomplishing the same without the added overhead of my perl module? You can use 1. mod_proxy: ProxyPass /images/http://image.site/image/ 2. mod_accel: AccelPass /images/http://image.site/image/ 3. default-handler - images must be on the same host: Location /images/ SetHandler default-handler /Location Igor Sysoev
Re: Creating a proxy using mod_perl
On Fri, 15 Mar 2002, Igor Sysoev wrote: On Fri, 15 Mar 2002, Marius Kjeldahl wrote: Any other ways of accomplishing the same without the added overhead of my perl module? You can use 1. mod_proxy: ProxyPass /images/http://image.site/image/ I'd go for this, perhaps with mod_rewrite or a PerlTransHandler since you'll want to proxy for more than one company's site. -- steven 1;
Re: Creating a proxy using mod_perl
On Fri, 15 Mar 2002, Marius Kjeldahl wrote: I guess these all suffer from the fact that the parameters have to be specified in httpd.conf, which makes it impossible to pass a url to fetch from in a parameter, right? So mod_rewite with mod_proxy or mod_accel: RewriteRule /proxy_url=http://(.+)$http://$1 [L,P] Note that 'proxy?url=' is changed to 'proxy_url='. Igor Sysoev
Re: Creating a proxy using mod_perl
At 05:11 PM 3/15/2002 +0300, Igor Sysoev wrote: On Fri, 15 Mar 2002, Marius Kjeldahl wrote: I guess these all suffer from the fact that the parameters have to be specified in httpd.conf, which makes it impossible to pass a url to fetch from in a parameter, right? So mod_rewite with mod_proxy or mod_accel: RewriteRule /proxy_url=http://(.+)$http://$1 [L,P] Note that 'proxy?url=' is changed to 'proxy_url='. Any concern about being an open proxy there? I'd want to only proxy the sites I'm working with. I'd rather cache the images locally, just in case you are working with a slow site or if they do something silly like check referer on requests. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Creating a proxy using mod_perl
On Fri, 15 Mar 2002, Bill Moseley wrote: At 05:11 PM 3/15/2002 +0300, Igor Sysoev wrote: On Fri, 15 Mar 2002, Marius Kjeldahl wrote: I guess these all suffer from the fact that the parameters have to be specified in httpd.conf, which makes it impossible to pass a url to fetch from in a parameter, right? So mod_rewite with mod_proxy or mod_accel: RewriteRule /proxy_url=http://(.+)$http://$1 [L,P] Note that 'proxy?url=' is changed to 'proxy_url='. Any concern about being an open proxy there? I'd want to only proxy the sites I'm working with. I'd rather cache the images locally, just in case you are working with a slow site or if they do something silly like check referer on requests. My prefrence is using static parameters in httpd.conf: AccelPass /mercant1/http://mercant1/umages/ AccelPass /mercant2/http://mercant2/umages/ ... AccelPass /mercant3/http://mercant3/umages/ And of course proxied images can be cached. Igor Sysoev
Re: problems returning a hash of hashes using mod_perl
On Thu, 2002-03-14 at 10:46, [EMAIL PROTECTED] wrote:
code:
| return %Actions::Vars::config{$conf}; |
-
You are not access the hash with the proper syntax:
%Actions::Vars::config
refers to the entire config hash, while:
$Actions::Vars::config{$conf}
will return you a value from that hash. Notice the leading '%' has been
replaced with a '$'. Read the 'perldsc' man page:
man perldsc
G
[OT]Re: problems returning a hash of hashes using mod_perl
At 15:46 14.03.2002 -0300, [EMAIL PROTECTED] wrote:
im using mod_perl with a module which stores all the configurations, and
embperl for displaying the wepages
a sub in this .pm has to return a hash with the configurations
but that hash is inside another general hash called configurations, this is
because each user of the program has its own configurations
the sentence im using to return the value is this
code:
| return %Actions::Vars::config{$conf}; |
-
being Actions::Vars:: the name of the package, config the general hash and
$conf the name of the subhash
remember that i need the entire subhash.. not values from it
this isn´t working, and because im not very expreinced with perl i searched
across with all the documentations i could find and never an example of
something like this
if you could help i´ll greatly apreciate it
Hi,
You should read the perllol documentation. It has got lots of information
about what you're talking about. This isn't a mod_per specific issue.
First of all:
the subhash you are referring to is just a value of the
%Action::Vars::config has. So you retrieve it like this:
$hashref = $Actions::Vars::config{$conf}
Now, that gives you a hash reference, from which you can access values
using $hashref-{key} ou $$hashref{key}.
If you want to retrieve the hash in normal form, like this:
my %conf = get_conf($conf);
You need to access all the values of the sub-hash.
So you get:
return %{$Actions::Vars::config{$conf}};
and then you can do:
my %hash = get_conf($conf); (or whatever)
This is actualle equivalent to:
my $hashref = $Actions::Vars::config{$conf};
my %hash = %$hashref;
Again, see perllol, it'll give you insight into this matter.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: [OT]Re: problems returning a hash of hashes using mod_perl
At 19:53 14.03.2002 +0100, Per Einar Ellefsen wrote: Again, see perllol, it'll give you insight into this matter. Oops, like Garth pointed out, this is supposed to be perldsc, and not perllol (which gives a description of arrays of arrays, which work in a similar way). -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: problems returning a hash of hashes using mod_perl
[EMAIL PROTECTED] wrote:
[snip]
| return %Actions::Vars::config{$conf}; |
-
Must read:
return $Actions::Vars::config{$conf}; # returns a hash reference
or
return % { $Actions::Vars::config{$conf} || {} }; # returns plain hash
and should have been created like this:
my %user_conf = ( foo = 1, bar = 'on' );
$Actions::Vars::config{'user'} = { %user_conf };
One more tip: always say:
use strict;
use warnings;
That should have told you, whats wrong ;-))
See also
http://www.perldoc.com/perl5.6/pod/perldsc.html#Declaration-of-a-HASH-OF-HASHES
Ernest
--
*
* VIRTUALITAS Inc. * *
** *
* European Consultant Office * http://www.virtualitas.net *
* Internationales Handelszentrum * contact:Ernest Lergon *
* Friedrichstraße 95 *mailto:[EMAIL PROTECTED] *
* 10117 Berlin / Germany * ums:+49180528132130266 *
*
Re: problems returning a hash of hashes using mod_perl
tnks a lot to all of you for the quick answers.. it now recognizes the hash im sending to, but its complaining a bit about the values.. saying it cat find the values for the keys.. but i don´t think this will be a real problem... it must be some gramatical eror or something tnks again Fernando Racca Esta comunicación es exclusivamente para fines informativos. Está dirigida al destinatario y puede contener información confidencial de Apsys SRL. No constituye una oferta o solicitud de compra o venta de ningún servicio o producto, o como la confirmación oficial de ninguna transacción. Cualquier comentario o afirmación vertida en esta comunicación, no reflejan necesariamente la posición de Apsys SRL. Si lo recibió por error, por favor bórrelo y avise de inmediato al emisor.
Re: problems returning a hash of hashes using mod_perl
Actually i found out that this was the correct answer
code:
| return %{$Actions::Vars::config{$conf}}; |
-
tnks all for taking the time to answer
Fernando Racca
Esta comunicación es exclusivamente para fines informativos. Está dirigida
al destinatario y puede contener información confidencial de Apsys SRL. No
constituye una oferta o solicitud de compra o venta de ningún servicio o
producto, o como la confirmación oficial de ninguna transacción. Cualquier
comentario o afirmación vertida en esta comunicación, no reflejan
necesariamente la posición de Apsys SRL. Si lo recibió por error, por favor
bórrelo y avise de inmediato al emisor.
Re: Doing Authorization using mod_perl from a programmersperspective
To insert a new comment on this old item: What about sockets? I am in the middle of trying to use $c = $r-connection and $c-remote_addr as part of the cookie name. (So far I am having trouble with the fact that remote_addr returns packed info, and I am still searching for how to unpack it - if you know, tell me!). It's not 'foolproof', but how many casual cookie stealers can force their browser to use a particular socket? This little method would even allow me to open multiple windows into a secured area, each with a different username, etc. (Very usefull during user interface development, etc. where menus differ based on some criteria for users) --Jon Robison David Young wrote: fliptop wrote: Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. The session hijacker would not need to know the username and password. They would only need to sniff the cookie from the network, and then send it from a client identifying itself as the same User Agent. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response.
Re: Doing Authorization using mod_perl from a programmersperspective
From: Jon Robison [EMAIL PROTECTED] What about sockets? I am in the middle of trying to use $c = $r-connection and $c-remote_addr as part of the cookie name. (So far I am having trouble with the fact that remote_addr returns packed info, and I am still searching for how to unpack it - if you know, tell me!). It's not 'foolproof', but how many casual cookie stealers can force their browser to use a particular socket? How would this be effective? If multiple users are behind a firewall that uses NAT, they will all have the same remote IP address. As for the remote port, that changes from connection to connection so it's not possible to use it as a reliable indicator either.
Re: Doing Authorization using mod_perl from aprogrammersperspective
I would still say this is dangerous. There is no guarantee that the same client will use the same IP and/or socket every time. Think about the thousands of AOL users behind hundreds of proxies. There is no consistency. Even with 10 users behind one NAT firewall I bet you'll have problems. From: Jon Robison [EMAIL PROTECTED] Date: Mon, 10 Dec 2001 18:06:00 -0500 Cc: [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmersperspective To insert a new comment on this old item: What about sockets? I am in the middle of trying to use $c = $r-connection and $c-remote_addr as part of the cookie name. (So far I am having trouble with the fact that remote_addr returns packed info, and I am still searching for how to unpack it - if you know, tell me!). It's not 'foolproof', but how many casual cookie stealers can force their browser to use a particular socket? This little method would even allow me to open multiple windows into a secured area, each with a different username, etc. (Very usefull during user interface development, etc. where menus differ based on some criteria for users) --Jon Robison David Young wrote: fliptop wrote: Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. The session hijacker would not need to know the username and password. They would only need to sniff the cookie from the network, and then send it from a client identifying itself as the same User Agent. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response.
Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? I've been out of town and am coming at this thread late. In case nobody else has mentioned it, HTTP_USER_AGENT values are 1) non- unique, and 2) often shared by applications on a single host (true especially for Microsoft environments). -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: Doing Authorization using mod_perl from a programmers perspective
fliptop == fliptop [EMAIL PROTECTED] writes: fliptop i have found that using the HTTP_USER_AGENT environment fliptop variable instead of ip address solves the problem with proxy fliptop servers and the md5 hash. anyone ever tried this as a simple fliptop workaround? Nobody with any sense. It's flawed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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: Doing Authorization using mod_perl from a programmers perspective
Randall, you want to expound upon that? --Jon Robison Randal L. Schwartz wrote: fliptop == fliptop [EMAIL PROTECTED] writes: fliptop i have found that using the HTTP_USER_AGENT environment fliptop variable instead of ip address solves the problem with proxy fliptop servers and the md5 hash. anyone ever tried this as a simple fliptop workaround? Nobody with any sense. It's flawed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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: Doing Authorization using mod_perl from a programmers perspective
How about using an Apache::Sessions id instead of IP address? --Jon Robison Randal L. Schwartz wrote: fliptop == fliptop [EMAIL PROTECTED] writes: fliptop i have found that using the HTTP_USER_AGENT environment fliptop variable instead of ip address solves the problem with proxy fliptop servers and the md5 hash. anyone ever tried this as a simple fliptop workaround? Nobody with any sense. It's flawed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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: Doing Authorization using mod_perl from a programmers perspective
Jon == Jon Robison [EMAIL PROTECTED] writes: Jon Randall, you want to expound upon that? Barely ignoring the spelling of my name, I'll simply claim it's not unique. Neither is IP address. Or anything that you haven't specifically round-tripped to the browser. And that doesn't stop someone from making another browser respond in the same way, or that browser respond in a different way. But this is obvious. I'm confused about why I'd have to explain it. :( -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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: Doing Authorization using mod_perl from a programmers perspective
On Mon, Nov 19, 2001 at 07:51:55AM -0800, Randal L. Schwartz wrote: But this is obvious. I'm confused about why I'd have to explain it. :( I posted this a year or two back: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/jytwortwor/[EMAIL PROTECTED] Here is the relevant part of that post: It makes sense to start with the requirements for what it means to implement those secure features. My requirements have an obvious e-commerce bias, and should probably be heavily reviewed by anyone thinking of using this design for online banking or government work. First, I'd like to introduce the notion of a secure session. Secure sessions have some subtle differences from the traditional notion of the session, and I'll point those out when they appear. The secure session has the following properties: *) The user is able to initiate a secure session by providing proper credentials (i.e., a username and password pair) via a login process. *) The user is able to terminate the secure session via a logout process. *) Secure sessions must be able to time out automatically. *) Secure sessions must *never* transmit sensitive data (such as the password) over insecure channels. *) The secure session, while it requires the use of a secure protocol (such as HTTPS), should not require the use of cookies. Cookies, however, can be employed to extend the functionality of the system. Additionally, I feel that one of the essential requirements to any enterprise quality, highly scalable, and fault-tolerant system is the ability to store session state on a tier other than the front-end. This usually means storing state in a shared database, but there are other options. A very effective method of meeting the requirements above is to use a two token architecture. The first token is a user identifier, which can be passed over insecure channels. This user identification token can be used to restore state that isn't particularly sensitive, such as a shopping cart or user preferences. The second token is a secure identifier, which is never passed over insecure channels. The secure identifier is required to access sensitive data, such as credit card data. (It is possible to create an architecture that uses *only* the secure token, but there are significant benefits in terms of flexibility afforded by using two tokens, so I won't go into the one token model here.) The fundamental goal of the secure token is to a) keep it safe from prying eyes, and b) use it is a requirement for accessing secure data. Tokens can be passed in one of two ways. First, the token can be passed as part of the URL. Second, the token can be passed in a cookie. I've found it very useful to create an initialization procedure inside applications that check both places for these tokens, and abstract the particular mechanism used to pass them. Note, however, that is important to remember how the token was passed -- if it came from a cookie, it is cosmetic to not pass it around in the URL. I also recommend creating a library used in your templates that has a function to build URLs that automatically append the tokens if necessary. Since it is critical that secure tokens are never passed in the clear, it really helps to have that function, because it can prevent the secure token from being sent via an insecure page in a URL (i.e., only setting secure tokens in URLs that contain https). The user identification token is typically used to restore state from the database. It is created whenever a page is viewed and the client has either not provided one (via the URL or a cookie), or the token they provide doesn't exist in the database. This token should then be set in both the URL and in a cookie. On the subsequent page request, if the user identification token is found in a cookie, it is probably safe to stop putting it in the URL. However, if the token is found only in the URL (probably meaning the client does not use cookies) the server should not try writing the cookie again. The advantage of the cookie is such that the user can insecurely identify themselves across browser sessions. This is perfectly acceptable when used to restore some insensitive state data (such as a name or shopping cart). However, the system still functions without the cookie. The user can now login to associate their client with particular stored user information. The login process is as follows: 1) The client connects to a secure page that presents a form requesting a username and password. (There has been much discussion about whether a HTTP form that POSTS to a secure page will encrypt the posted data. There is too much ambiguity here -- I recommend using HTTPS on the login form as well.) The ACTION of the form must also be a secure page. 2) On receiving the username and password, the server compares an encrypted version of the password with the stored encrypted password associated with that customer. If the passwords do not match,
Re: Doing Authorization using mod_perl from a programmers perspective
* Randal L. Schwartz ([EMAIL PROTECTED]) [09 11:00]: Jon == Jon Robison [EMAIL PROTECTED] writes: Jon Randall, you want to expound upon that? Barely ignoring the spelling of my name, I'll simply claim it's not unique. Neither is IP address. Or anything that you haven't specifically round-tripped to the browser. And that doesn't stop someone from making another browser respond in the same way, or that browser respond in a different way. But this is obvious. I'm confused about why I'd have to explain it. :( I think Randal has pointed out many times, as have others, that a browser isn't a person. One doesn't want to authenticate browsers, one wants to authenticate people. Using browser specific information to authenticate a person is not only impossible to do successfully, it is silly to try. Using cookies is only a little bit less unsuccessful. Also, please be sure to note the gotcha in the mod_perl guide that gives you warning that all browsers behave differently when dealing with a 401 status code. Be sure to take that into account. Thanks, JJ -- J. J. Horner H*,6a686f726e657240326a6e6574776f726b732e636f6d *** H*,6a6a686f726e65724062656c6c736f7574682e6e6574 Freedom is an all-or-nothing proposition: either we are completely free, or we are subjects of a tyrannical system. If we lose one freedom in a thousand, we become completely subjugated. msg22686/pgp0.pgp Description: PGP signature
Re: Doing Authorization using mod_perl from a programmers perspective
Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server.
Re: Doing Authorization using mod_perl from a programmersperspective
fliptop wrote: Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. The session hijacker would not need to know the username and password. They would only need to sniff the cookie from the network, and then send it from a client identifying itself as the same User Agent. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response.
RE: Doing Authorization using mod_perl from a programmers perspective
my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response. the IP address is really a poor choice if I understand AOL and other large-scale proxies enough - they use a round-robin IP scheme where multiple requests _from the same user_ can appear as different IP addresses. the cool thing about the MD5 hashing scheme is that any would-be hacker needs to know the fields you are hashing in order to have a chance at creating a like hash. so, if you use stuff transmitted in the clear (like username, sessionid, some bogus piece of info not used, and MD5 hash) as well as other stuff obtainable from the transaction (like user-agent, protocol, method, accept header) and combine some random form of these (along with a server-side-only secret) the hash should be reasonably secure. this is kind of how digest authentication works (except there the algorithm is published, so you know the parameters involved). --Geoff
RE: Doing Authorization using mod_perl from a programmers perspec tive
the cool thing about the MD5 hashing scheme is that any would-be hacker needs to know the fields you are hashing in order to have a chance at creating a like hash. so, if you use stuff transmitted in the clear (like username, sessionid, some bogus piece of info not used, and MD5 hash) as well as other stuff obtainable from the transaction (like user-agent, protocol, method, accept header) and combine some random form of these (along with a server-side-only secret) the hash should be reasonably secure. this is kind of how digest authentication works (except there the algorithm is published, so you know the parameters involved). forgot to mention that you could also encrypt the entire thing in the cookie using something like Apache::Cookie::Encrypted, which uses blowfish or some other cypher. Apache::Cookie::Encrypted is pretty neat, except it doesn't do inheritance correctly so you can't subclass it, but it should prove as a good starting point for another effort... --Geoff
Re: Doing Authorization using mod_perl from a programmers perspective
fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
RE: Doing Authorization using mod_perl from a programmers perspective
The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmersperspective
Yes I remember reading about this some time ago. Of course I am short on specifics, but IIRC those were some sort of signature put in by ISPs who were bundling IE, and the id transmitted only configuration info but not specific user details. From: Stephen Adkins [EMAIL PROTECTED] Date: Fri, 16 Nov 2001 12:13:48 -0500 To: Joe Breeden [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: RE: Doing Authorization using mod_perl from a programmers perspective Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!)
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmers perspective
Jonathon,
I am doing exactly this also. What works is this:
Get a copy of Writing Apache modules with perl and C and read it.
The most relevant section for you is the Ticket system he describes. (I
believe the section header says something about Cookies, but you'll know
you have the right one when you see TicketAccess.pm, TicketTools.pm, and
TicketMaster.pm. One nice addition is the ability to add encryption to
the Ticket, and the fact that the author used an MD5 hash (of an MD5
hash!) in the cookie, so verification of the authenticity of the user is
pretty solid so long as you leave in things like ip address, etc. which
he uses in the cookie by default. (Although AOL and some proxy systems
might cause this to be trouble). AND, he also uses a mysql db for the
passwords, etc. All in all, a VERY usefull section of the book.
As for pushing content after authorization, take a very close look at
the $r-push_handler() function. I use it like this:
my $input = $r-args (or however you want to get input - Apache::Request
is a good way)
if (defined $input-{some_param}) {
$r-push_handler( PerlHandler = MyActionModule );
} else {
$r-push_handler(PerlHandler = MyErrorModule );
}
Because the request object (usually $r) exists in it's same state when
the new PerlHandler is called, grabbing $input again (via whatever
method) can be used to determine what action the module takes.
This isn't precise, so please read the manual before using this, but you
get the idea. One thing to keep in mind is that perl_handlers
(PerlHandler) is a stack that will draw from the top, so it is FILO, not
FIFO.
Hope this helps.
Jonathon Robison
Uniphied Thought, LLC.
Jonathan E. Paton wrote:
I am trying to create a website with predominantly dynamic
content (mod_perl + DBI + mySQL) for an online community.
I can manage Perl and mySQL fairly proficently, however
I've no idea how to successfully create what I want using
mod_perl and Apache (actually, I know next to nothing about
them).
--- Background information ---
The website shall be split into a public and private
section, and will share a common layout and appearance
(although I might add little visual clues to indicate which
section they are in). When members wish to login I want
them to do so via the public section (from that page), and
then be able to access the additional links/features of the
private section.
I wish to handle all the database actions in my own code,
unless something fits perfectly. When members try to
login, my aims are:
1. Check login name, and password.
2. Check member hasn't been suspended.
3. Return the membership ID number for the next stage.
The membership ID number will be used to decide what access
level the members have (what forums, tools etc they can see
and use). The SQL table is specified as:
CREATE TABLE access (
member_id int(10) unsigned NOT NULL,
account_name varchar(16) NOT NULL,
account_password varchar(16) NOT NULL,
state enum('A', 'S') DEFAULT 'A' NOT NULL,
PRIMARY KEY (account_name)
);
Imagine I now create an object to wrap around this, with
the following method:
my $permission = $access-check($account_name,
$account_password);
which returns the membership number if valid,
or the value -1 for a suspended account,
or undef for no account.
--- Questions ---
1. Can this be done (nicely) as a
authentication/authorization handlier?
2. Do most hosting companies allow
authentication/authorization handlers? (Using HostRocket
at the moment).
3. What is the most appropriate session management system?
I'm thinking of using cookies (client side) to store a
session key, rather than resubmitting the password data.
The server side stores this session key in the database.
4. How does the membership ID get passed to the next stage?
5. What is the time to do additional access checking (for
senior/admin users)? I was planning to do it a little
later on, but it is probably better to do it once (i.e.
with this).
6. What is a realistic time to expect all this to happen
in?
I'm sure I've missed a few questions...
Any help appriecated, especially links to relevent
documentation.
Jonathan Paton
NB - Whilst my preferred answer to these questions is a
coded solution, I have a restriction (self imposed) - I'd
prefer to have full copyright on the final code, thus I ask
any major ideas/code includes permission to use it freely -
or else be good enough to be worth adding your name provide
I use it :)
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround?
RE: Doing Authorization using mod_perl from a programmers perspective
How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: fliptop [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:50 PM To: Jon Robison Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround?
Doing Authorization using mod_perl from a programmers perspective
I am trying to create a website with predominantly dynamic
content (mod_perl + DBI + mySQL) for an online community.
I can manage Perl and mySQL fairly proficently, however
I've no idea how to successfully create what I want using
mod_perl and Apache (actually, I know next to nothing about
them).
--- Background information ---
The website shall be split into a public and private
section, and will share a common layout and appearance
(although I might add little visual clues to indicate which
section they are in). When members wish to login I want
them to do so via the public section (from that page), and
then be able to access the additional links/features of the
private section.
I wish to handle all the database actions in my own code,
unless something fits perfectly. When members try to
login, my aims are:
1. Check login name, and password.
2. Check member hasn't been suspended.
3. Return the membership ID number for the next stage.
The membership ID number will be used to decide what access
level the members have (what forums, tools etc they can see
and use). The SQL table is specified as:
CREATE TABLE access (
member_id int(10) unsigned NOT NULL,
account_name varchar(16) NOT NULL,
account_password varchar(16) NOT NULL,
state enum('A', 'S') DEFAULT 'A' NOT NULL,
PRIMARY KEY (account_name)
);
Imagine I now create an object to wrap around this, with
the following method:
my $permission = $access-check($account_name,
$account_password);
which returns the membership number if valid,
or the value -1 for a suspended account,
or undef for no account.
--- Questions ---
1. Can this be done (nicely) as a
authentication/authorization handlier?
2. Do most hosting companies allow
authentication/authorization handlers? (Using HostRocket
at the moment).
3. What is the most appropriate session management system?
I'm thinking of using cookies (client side) to store a
session key, rather than resubmitting the password data.
The server side stores this session key in the database.
4. How does the membership ID get passed to the next stage?
5. What is the time to do additional access checking (for
senior/admin users)? I was planning to do it a little
later on, but it is probably better to do it once (i.e.
with this).
6. What is a realistic time to expect all this to happen
in?
I'm sure I've missed a few questions...
Any help appriecated, especially links to relevent
documentation.
Jonathan Paton
NB - Whilst my preferred answer to these questions is a
coded solution, I have a restriction (self imposed) - I'd
prefer to have full copyright on the final code, thus I ask
any major ideas/code includes permission to use it freely -
or else be good enough to be worth adding your name provide
I use it :)
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
Re: Doing Authorization using mod_perl from a programmers perspective
Hi there, On Wed, 14 Nov 2001, [iso-8859-1] Jonathan E. Paton wrote: I am trying to create a website [snip] NB - Whilst my preferred answer to these questions is a coded solution, [snip] We like people to think for themselves on this list. :) I'm sure I've missed a few questions... Read http://perl.apache.org/guide and Writing Apache Modules with Perl and C, ISBN 1-56592-567-X (otherwise known as the Eagle Book) which will answer almost all the questions you can think of, and a great many that you can't (yet). Some of your questions have no answer. Please don't ask questions that are answered in these publications on this list, people here have a habit of directing you to them for guidance. This implies a lot of patience on your part, because they are fairly lengthy and concentrated technical works, and not much patience on our part (for whatever reasons :). Despite the quip about thinking people above, there are lots of coded solutions in these books which you can adapt or otherwise mangle. TMTOWTDI y'know. 73, Ged.
Re: Doing Authorization using mod_perl from a programmers perspective
1. Can this be done (nicely) as a authentication/authorization handlier? Sure, or you could do it as part of another phase if it's easier for you. There are good exmples on CPAN or in the Eagle book. 2. Do most hosting companies allow authentication/authorization handlers? (Using HostRocket at the moment). Most hosting companies don't allow mod_perl. 3. What is the most appropriate session management system? I'm thinking of using cookies (client side) to store a session key, rather than resubmitting the password data. The server side stores this session key in the database. That sounds fine. There are examples of this in the book too. Make sure your session keys can't be forged. 4. How does the membership ID get passed to the next stage? It's typically stored in the session data. 5. What is the time to do additional access checking (for senior/admin users)? Impossible to answer. Totally depends on your setup. 6. What is a realistic time to expect all this to happen in? Also impossible to answer, since it depends on your developers and the full requirements. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
Hi, Perrin Harkins wrote: 2. Do most hosting companies allow authentication/authorization handlers? (Using HostRocket at the moment). Most hosting companies don't allow mod_perl. I had fears about that one, since I thought Perl might not mean mod_perl - as I know mod_perl is rather cosy with Apache (that's the whole point). With the functionality I had in mind it'd take too long to compile them on the fly. Seemingly I can do Apache handlers though, so I *might* be okay. Looks like I may have to run it off my friends ADSL connection, as I'm stuck in 56k hell. That adds nice domain redirection and uptime problems (of ADSL) to my life ;-) 6. What is a realistic time to expect all this to happen in? Also impossible to answer, since it depends on your developers and the full requirements. My developers? - What's a developer? :P The best I've got are inexperienced amatures with relevatively little coding experience with Perl. Tough challenge eh? With some determination we'll get it finished by Christmas (not this year :P ) I rather ambigously asked the question: How many milliseconds might this stage take, on a commerial hosting company's servers. Suppose without mod_perl this would be at least 300ms, or probably worse. Ged Haywood wrote: I am trying to create a website [snip] NB - Whilst my preferred answer to these questions is a coded solution, [snip] We like people to think for themselves on this list. :) Okay, I forgot the smiley on that. I don't really expect anyone to code it for me, that's asking too much... unless people are willing to share what they've already done. I'd owe someone too many brownie points if they coded it for me. The Background was there for interest really, and to suggest what I'm trying to do. Please don't flame me, I'll go away... honest :P Jonathan Paton __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: Doing Authorization using mod_perl from a programmers perspective
Seemingly I can do Apache handlers though, so I *might* be okay. If you look at http://perl.apache.org/guide/, there's information on how to determine if you're really running mod_perl or not. If you can get a PerlHandler directive to work, you have mod_perl. I rather ambigously asked the question: How many milliseconds might this stage take, on a commerial hosting company's servers. Suppose without mod_perl this would be at least 300ms, or probably worse. It depends on what you're doing in that stage. In relative terms, programs that access databases usually run many times faster in mod_perl than with CGI. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
Jonathan E. Paton [EMAIL PROTECTED] writes: Please don't flame me, I'll go away... honest :P I wonder if you're trying to do too much too soon? If you're concerned about hosting then *gulp* PHP might server you better. I rent a dedicated server because I want absolute control and the ability to run my own handler. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
RE: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
-Original Message- From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. From what I can tell from the Apache 1.3.22 build, here's how to get it stable: 1. Install libexpat. 2. Install perl 3. Install XML::Parser 2.30 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. ** Do not use APXS to build mod_perl ** The recipe in the AxKit INSTALL file seems to work best for people doing XML stuff inside mod_perl: $ perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ DYNAMIC=1 \ APACHE_PREFIX=/opt/apache \ APACHE_SRC=../apache_1.3.22/src \ DO_HTTPD=1 \ APACI_ARGS=--enable-module=so --enable-shared=info --enable-shared=proxy --enable-shared=rewrite --enable-shared=log_agent $ make $ su $ make install However, that also builds Apache with --disable-rule=expat, so it might kinda defeat your purpose :-) If you *really* need the expat in Apache, I think you can add in there --enable-rule=expat, but I haven't tried it. If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, think about doing that anyway :-) Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Just to follow up. I took your advice on building building modperl. My actual command was as follows: perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ APACHE_PREFIX=/lsurf/wohg \ APACHE_SRC=../$APACHE/src \ DO_HTTP=1 \ APACI_ARGS=--enable-rule=expat --enable-module=so --enable-shared=info \ --enable-shared=proxy --enable-shared=rewrite I first tried this with perl 5.005_3 with no problems. I then upgraded to perl 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty bug showed back up. At this point it still looks like I'm SOL using XML::Parser with perl 5.6.1 under modper. I did download and install XML::LibXML and started playing with it. I'm actually using XML::Parser via XML::Simple to put short XML messages into handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) Thanks for the help, Matthew Matt Sergeant wrote: -Original Message- From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. From what I can tell from the Apache 1.3.22 build, here's how to get it stable: 1. Install libexpat. 2. Install perl 3. Install XML::Parser 2.30 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. ** Do not use APXS to build mod_perl ** The recipe in the AxKit INSTALL file seems to work best for people doing XML stuff inside mod_perl: $ perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ DYNAMIC=1 \ APACHE_PREFIX=/opt/apache \ APACHE_SRC=../apache_1.3.22/src \ DO_HTTPD=1 \ APACI_ARGS=--enable-module=so --enable-shared=info --enable-shared=proxy --enable-shared=rewrite --enable-shared=log_agent $ make $ su $ make install However, that also builds Apache with --disable-rule=expat, so it might kinda defeat your purpose :-) If you *really* need the expat in Apache, I think you can add in there --enable-rule=expat, but I haven't tried it. If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, think about doing that anyway :-) Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Matthew H. Gerlach wrote: Just to follow up. I took your advice on building building modperl. My actual command was as follows: perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ APACHE_PREFIX=/lsurf/wohg \ APACHE_SRC=../$APACHE/src \ DO_HTTP=1 \ APACI_ARGS=--enable-rule=expat --enable-module=so --enable-shared=info \ --enable-shared=proxy --enable-shared=rewrite I first tried this with perl 5.005_3 with no problems. I then upgraded to perl 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty bug showed back up. At this point it still looks like I'm SOL using XML::Parser with perl 5.6.1 under modper. I did download and install XML::LibXML and started playing with it. I'm actually using XML::Parser via XML::Simple to put short XML messages into handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) i would say that XML::LibXML is the most stable modules ive used everything else perl has failed for the X3D parsing tool i made: http://drfrog.fdns.net/perl/parsex3d.pl this will have a much nicer home at web3d.org at some point soon they found a bug in it on freebsd timezone related iirc
Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Hi gang, I am fairly new to mod_perl, but I would like to share my recent experience and hope someone might offer some insight into my troubles. Last week I whipped together a simple perl module that used XML::Simple ( a wrapper for XML::Parser) to parse some POST'd content. Once parsed the resulting data was munched a bit and then POST'd to another web server. Like everything perl it was quick to implement and ran quick as well. My problems came along when I moved my module to another server. All of sudden Apache would segfault in the Expat library code when my module parsed the content. I noticed that I had different versions of XML::Parser on the different machines (2.29 vs. 2.30). XML::Parser-2.29 was the one on the working instance so I downgraded the box that was segfaulting. When I down graded the segfaults went away but a nasty little problem showed up latter in the module where the data being sent in my module's post was getting corrupted. I narrowed down the problem to the call to running the XML parser being related to the data corruption. At this point I found this mail list and searched the archive. There were lots of references to the Expat problem where Apache itself uses a copy of Expat and a XML::Parser would use a different version of the Expat. There was discussion about required configuration parameters to mod perl, but more importantly there was a post mentioning that Apache 1.3.22 made the whole problem go away. Feeling inspired by my new found knowledge of the problem, I decided a clean install of the new apache was in order. To be safe, I reinstalled RedHat 7.1 without RedHat's apache. I uninstalled perl 5.6.0 that came with RH7.1 and installed perl 5.6.1. I followed the simple mod_perl install instructions that builds apache with perl statically linked. My resulting install didn't segfault, but my nasty bug was still there. At this point I went back and fully duplicated the working implementation: Apache 1.3.19, mod_perl 1.26 perl-5.005_3 and XML::Parser-2.29. The originally working system was on RH 6.2, and this configuration worked on my new machine using RH 7.1. This configuration was built with the following commands: tar zxf apache_1.3.19.tar.gz cd apache_1.3.19 ./configure --prefix=/lsurf/apache --enable-shared=max --enable-module=all make make install cd .. tar zxf mod_perl-1.26.tar.gz cd mod_perl-1.26 perl Makefile.PL USE_APXS=1 APACHE_PREFIX=/lsurf/apache EVERYTHING=1 make make install Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. In the end I have a working implementation using perl-5.005_3, but I'd sure feel better using the latest stable perl, and it should work as far as I can tell. If anyone has some suggestions I'd be willing to give them a try. Thanks for your patience if you read this long winded post. Matthew
Re: using mod_perl
try looking at http://perl.apache.org/ /jon [EMAIL PROTECTED] wrote: Hi! I am wondering if anyone could tell me how to actually run modperl on my webserver i have perl modules installed to run without modperl and dont know how to invoke the process to get them working can anyone help? jason
Re: using mod_perl
Hi! I am wondering if anyone could tell me how to actually run modperl on my webserver i have perl modules installed to run without modperl and dont know how to invoke the process to get them working can anyone help? jason The best place to learn mod_perl is the Guide: http://perl.apache.org/guide Sorry for the 'RTFM' reply, but you'll find that this document answers beginner questions better than anyone here can in a quick email, and it's kept very up to date thanks to the marvellous Stas Bekman.
Looking for answers using mod_perl and windows nt.
I am using Windows NT, running apache with mod_perl.
The problem that I am having is that I am dynamiclly filling in the options
of a select box from a
database. now when a user selects a value, I expect that value to be on the
URL, but it is not. I
am currently saving the selected value to a hidden field, which does show up
on the URL. Anyone
know the reason why.
I did come up with a work around but have now clue as to why it works. here
is a bit of the javascript
that creates the select box and the html:
function populateComboBoxes()
{
var sDisplayValue = new Array([+ $cmbClientKeyText +]);
var sInternalValue = new Array([+ $cmbClientKeyValue +]);
var arr = new Array(sDisplayValue.length + 1);
arr[0] = option value=''( None Selected )/option;
for (var i=1; i sDisplayValue.length + 1; i++)
{
arr[i] = OPTION value=' + sInternalValue[i - 1] +' +
sDisplayValue[i - 1] + /OPTION;
}
divUpdate.innerHTML = SELECT name='cmbClientKey'
id='cmbClientKey' + arr.join() + /SELECT;
}
this gets populated from the javascript above and is displayed to the user
div name='divUpdate' id='divUpdate' class='divUpdate'
style=display:block
!--select name=cmbClientKey id=cmbClientKey
/select--
/div
this one is not populated from above and does not get displayed to the user,
if this is removed then cmbClientKey on the URL line
is blank.
div style=display:none
select name=cmbClientKey id=cmbClientKey
option value= ( None Selected ) /option
/select
/div
cmbClientKey is needed in order of other combo boxes data to be displayed
correctly.
any ideals as to why this is happening.
Re: Looking for answers using mod_perl and windows nt.
Boyd, David wrote: I am using Windows NT, running apache with mod_perl. The problem that I am having is that I am dynamiclly filling in the options of a select box from a database. now when a user selects a value, I expect that value to be on the URL, but it is not. I am currently saving the selected value to a hidden field, which does show up on the URL. Anyone know the reason why. I'm not sure I understand your question, David. If you're saying that you would expect the result of pressing a submit button in a form to be that request is sent like 'http://some.host/file.pl?combo=value', then you need to ensure that the form in your HTML is set to GET rather than POST style encoding. But that's not really a mod_perl issue...
RE: Looking for answers using mod_perl and windows nt.
lets see if I can clearify my statement.
first I am new to mod_perl.
Now, my form is using post. I am using some debug messages
that will output, in html format, the contents of $fdat. So,
when I select next page, after making a selection from the combo
box, i expected to see something like the following:
fdat{cmbClientKey} = something
I do not get this unless I have the items I posted in the previous
message.
...
-Original Message-
From: Jeremy Howard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 10:18 AM
To: Boyd, David; [EMAIL PROTECTED]
Subject: Re: Looking for answers using mod_perl and windows nt.
Boyd, David wrote:
I am using Windows NT, running apache with mod_perl.
The problem that I am having is that I am dynamiclly filling in the
options
of a select box from a
database. now when a user selects a value, I expect that value to be on
the
URL, but it is not. I
am currently saving the selected value to a hidden field, which does show
up
on the URL. Anyone
know the reason why.
I'm not sure I understand your question, David. If you're saying that you
would expect the result of pressing a submit button in a form to be that
request is sent like 'http://some.host/file.pl?combo=value', then you need
to ensure that the form in your HTML is set to GET rather than POST style
encoding. But that's not really a mod_perl issue...
RE: Looking for answers using mod_perl and windows nt.
I think I might have this figured out.
in my combobox, I had the following:
select name=cmbProgramKey id=cmbProgramKey
onChange=cmbProgramKey_OnChange(this.value)
option value= ( None Selected ) /option
[$ while( $rProgramArray ) $]
option value=[+ $$rProgramArray[0] +][+
$$rProgramArray[1] +]/option
[- $rProgramArray = $sthProgram-fetchrow_arrayref(); -]
[$ endwhile $]
/select
Now when I remove the first option value: option value= ( None Selected
) /option
and end up with
select name=cmbProgramKey id=cmbProgramKey
onChange=cmbProgramKey_OnChange(this.value)
[$ while( $rProgramArray ) $]
option value=[+ $$rProgramArray[0] +][+
$$rProgramArray[1] +]/option
[- $rProgramArray = $sthProgram-fetchrow_arrayref(); -]
[$ endwhile $]
/select
things seem to work.
Now the question is why?
-Original Message-
From: Boyd, David [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 10:21 AM
To: 'Jeremy Howard'; Boyd, David; [EMAIL PROTECTED]
Subject: RE: Looking for answers using mod_perl and windows nt.
lets see if I can clearify my statement.
first I am new to mod_perl.
Now, my form is using post. I am using some debug messages
that will output, in html format, the contents of $fdat. So,
when I select next page, after making a selection from the combo
box, i expected to see something like the following:
fdat{cmbClientKey} = something
I do not get this unless I have the items I posted in the previous
message.
...
-Original Message-
From: Jeremy Howard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 10:18 AM
To: Boyd, David; [EMAIL PROTECTED]
Subject: Re: Looking for answers using mod_perl and windows nt.
Boyd, David wrote:
I am using Windows NT, running apache with mod_perl.
The problem that I am having is that I am dynamiclly filling in the
options
of a select box from a
database. now when a user selects a value, I expect that value to be on
the
URL, but it is not. I
am currently saving the selected value to a hidden field, which does show
up
on the URL. Anyone
know the reason why.
I'm not sure I understand your question, David. If you're saying that you
would expect the result of pressing a submit button in a form to be that
request is sent like 'http://some.host/file.pl?combo=value', then you need
to ensure that the form in your HTML is set to GET rather than POST style
encoding. But that's not really a mod_perl issue...
RE: Looking for answers using mod_perl and windows nt.
I take it back, what seems to be happing is that the
first item in the select box is identified as selected. If
I select a different item in the list, the first one is always selected.
This gets stranger by the minute.
...
-Original Message-
From: Boyd, David [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 12:32 PM
To: 'Jeremy Howard'; [EMAIL PROTECTED]
Subject: RE: Looking for answers using mod_perl and windows nt.
I think I might have this figured out.
in my combobox, I had the following:
select name=cmbProgramKey id=cmbProgramKey
onChange=cmbProgramKey_OnChange(this.value)
option value= ( None Selected ) /option
[$ while( $rProgramArray ) $]
option value=[+ $$rProgramArray[0] +][+
$$rProgramArray[1] +]/option
[- $rProgramArray = $sthProgram-fetchrow_arrayref(); -]
[$ endwhile $]
/select
Now when I remove the first option value: option value= ( None Selected
) /option
and end up with
select name=cmbProgramKey id=cmbProgramKey
onChange=cmbProgramKey_OnChange(this.value)
[$ while( $rProgramArray ) $]
option value=[+ $$rProgramArray[0] +][+
$$rProgramArray[1] +]/option
[- $rProgramArray = $sthProgram-fetchrow_arrayref(); -]
[$ endwhile $]
/select
things seem to work.
Now the question is why?
-Original Message-
From: Boyd, David [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 10:21 AM
To: 'Jeremy Howard'; Boyd, David; [EMAIL PROTECTED]
Subject: RE: Looking for answers using mod_perl and windows nt.
lets see if I can clearify my statement.
first I am new to mod_perl.
Now, my form is using post. I am using some debug messages
that will output, in html format, the contents of $fdat. So,
when I select next page, after making a selection from the combo
box, i expected to see something like the following:
fdat{cmbClientKey} = something
I do not get this unless I have the items I posted in the previous
message.
...
-Original Message-
From: Jeremy Howard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 10:18 AM
To: Boyd, David; [EMAIL PROTECTED]
Subject: Re: Looking for answers using mod_perl and windows nt.
Boyd, David wrote:
I am using Windows NT, running apache with mod_perl.
The problem that I am having is that I am dynamiclly filling in the
options
of a select box from a
database. now when a user selects a value, I expect that value to be on
the
URL, but it is not. I
am currently saving the selected value to a hidden field, which does show
up
on the URL. Anyone
know the reason why.
I'm not sure I understand your question, David. If you're saying that you
would expect the result of pressing a submit button in a form to be that
request is sent like 'http://some.host/file.pl?combo=value', then you need
to ensure that the form in your HTML is set to GET rather than POST style
encoding. But that's not really a mod_perl issue...
Re: Using mod_perl to modify referer...
Brian [EMAIL PROTECTED] writes: I have a unique situation in which I need to change the http_referer. What I've done is written a quick script that looks like this: [snip] Now, the problem is this: It works perfectly as long as the client remains on our server. But, if they go to another domain the referer reverts back to what it was before. I need to change it, and have it stay changed. Is there ANY way of doing this with mod_perl? Any help is appreciated. I've been beating my head on the desk for a while here. :o) There is no way to do this. The REFERER field is set by the web client and can not be altered by the server. Once it's sent to the server as part of a HTTP request, the server is free to modify it as it sees fit (as you've done in mod_perl), but it can not tell the client to adopt this new value. Two possible workarounds would be to direct hyperlinks to an intermediate page which in turn redirects the client the final destination. That should set the REFERER correctly to the intermediate page (though perhaps not for 302 redirects). Another possibility would be to abandon using the REFERER field altogether. Use a cookie to encode the necessary information or encode it in the query string of the request itself.
Using mod_perl to modify referer...
I have a unique situation in which I need to change the http_referer.
What I've done is written a quick script that looks like this:
package BnP::Referer;
use Apache;
use Apache::Constants;
sub handler {
my $r = shift;
$r-header_in('Referer' = http://www.somedomainname.com;);
return OK;
}
1;
And then setup a handler in the httpd.conf file that looks like this:
PerlModule BnP::Referer
PerlFixupHandler BnP::Referer
Now, the problem is this: It works perfectly as long as the client
remains on our server. But, if they go to another domain the referer
reverts back to what it was before. I need to change it, and have it
stay changed. Is there ANY way of doing this with mod_perl? Any help
is appreciated. I've been beating my head on the desk for a while here.
:o)
Brian Johnson
Partner/Systems Administrator/Programmer
Source1Hosting.tv, LLC (www.source1hosting.tv)
Source1Results.com, LLC (www.source1results.com)
I may be insane, but remember - The only
difference between an insane man and a
genius is his jacket.
Re: [aliasing] Using mod_perl handlers for max speed?
Heh - you're on the wrong track. The whole quote below is part of a
double-quoted string, and each backslash is just to put a literal $ into
the code. It will be eval'ed later.
[EMAIL PROTECTED] (raptor) wrote:
!!! Is it possible to have reference on the left side of the equation !!!
I've tried this to alias HASH :) but didn't succeeded...
sub {
my \$hash = shift; # $_[0] is \%myhash
};
Yes I know that there is aliasing : my *hash = \%{$hashref}..
And I see that here u use : \$r-blah
Never mind it is cute construct anyway. Do U have any benefit in speed
using it in this way ?!
PS. didn't u think that there must finaly alias keyword in perl
=
iVAN
[EMAIL PROTECTED]
=
Files ~ (hello\.bench)
Perl
# ModPerl Handler
package Apache::bench;
sub handler {
my(\$r) = shift;
\$r-content_type('text/html');
\$r-send_http_header();
\$r-print('Hello ');
\$r-print('World');
200;
}
1;
/Perl
SetHandler perl-script
PerlHandler Apache::bench
/Files
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Using mod_perl handlers for max speed?
On Wed, 11 Jul 2001, Philip Mak wrote: In the recent Hello World 2000 benchmark posted by Joshua Chamas, mod_perl handler was shown to be even faster than static HTML (at least for running hello world), and twice as fast as using Apache::Registry to run a perl script. I honestly think something is up there. The code that mod_perl goes through before executing the actual perl script is a lot slower than the code the static HTML (http_core) handler goes through. FWIW, In AxKit 1.4_80 on axkit.org (beta, has bugs), I've implemented something I call a mod_perl fast handler, which skips most of the stuff in mod_perl, allowing you to go: AddHandler axkit .xml in your httpd.conf, and it works much the same way as SetHandler/PerlHandler does, except faster. Obviously though you lose the benefit of being able to write handlers for the different handler phases with this method. And it requires XS code. Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? What are the caveats of using mod_perl handlers instead of normal scripts? Using handlers is better. Hands down. :-) Personally I just find handlers more logical than CGI scripts. They have a known entry point, which I think makes life a hell of a lot easier in structuring complex code. Rather than the entry point being the top of your script. There's a beginners article on take23 about writing your first handler module. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: [aliasing] Using mod_perl handlers for max speed?
!!! Is it possible to have reference on the left side of the equation !!!
I've tried this to alias HASH :) but didn't succeeded...
sub {
my \$hash = shift; # $_[0] is \%myhash
};
Yes I know that there is aliasing : my *hash = \%{$hashref}..
And I see that here u use : \$r-blah
...Never mind it is cute construct anyway. Do U have any benefit in speed
using it in this way ?!
PS. didn't u think that there must finaly alias keyword in perl
=
iVAN
[EMAIL PROTECTED]
=
Files ~ (hello\.bench)
Perl
# ModPerl Handler
package Apache::bench;
sub handler {
my(\$r) = shift;
\$r-content_type('text/html');
\$r-send_http_header();
\$r-print('Hello ');
\$r-print('World');
200;
}
1;
/Perl
SetHandler perl-script
PerlHandler Apache::bench
/Files
Using mod_perl handlers for max speed?
In the recent Hello World 2000 benchmark posted by Joshua Chamas, mod_perl
handler was shown to be even faster than static HTML (at least for running
hello world), and twice as fast as using Apache::Registry to run a perl
script.
Does this mean that if there's a heavily used script on my system that
needs to be VERY fast, then it may be worth making it into a mod_perl
handler? What are the caveats of using mod_perl handlers instead of normal
scripts?
For those who didn't see it, here is the code for the Hello World mod_perl
handler program. It is inserted into httpd.conf directly.
Files ~ (hello\.bench)
Perl
# ModPerl Handler
package Apache::bench;
sub handler {
my(\$r) = shift;
\$r-content_type('text/html');
\$r-send_http_header();
\$r-print('Hello ');
\$r-print('World');
200;
}
1;
/Perl
SetHandler perl-script
PerlHandler Apache::bench
/Files
Re: Using mod_perl handlers for max speed?
Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? Not unless you get astonishing amounts of traffic and your script does almost nothing. These are very simple test cases, so they exaggerate the speed differences. (Intentionally.) However, you should be aware that handlers rock, and many of us consider them more fun than Registry scripts. Registry scripts have their fans as well, of course. What are the caveats of using mod_perl handlers instead of normal scripts? You can read more here: http://perl.apache.org/guide/porting.html#Transitioning_from_Apache_Regis - Perrin
Re: Using mod_perl handlers for max speed?
Philip Mak wrote: In the recent Hello World 2000 benchmark posted by Joshua Chamas, mod_perl handler was shown to be even faster than static HTML (at least for running hello world), and twice as fast as using Apache::Registry to run a perl script. Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? What are the caveats of using mod_perl handlers instead of normal scripts? Its hard to explain, but try not to focus on the Hits/sec, instead look at the sec/Hits. Notice that the difference between Registry CGI Raw and mod_perl handler is only ~ .00025 seconds. Test Name Test File Hits/sec Total Hits Total Time sec/Hits Bytes/Hit -- -- -- -- -- -- Apache::Registry v2.01 CGI Raw hello_raw. 669.9 40196 hits 60.00 sec 0.001493 52 bytes mod_perl handlerhello.benc 808.4 48522 hits 60.02 sec 0.001237 197 bytes You could easily use that much time with a half page of perl code for your application depending on what its doing, especially if you are doing some heavy lifting like writing to a file, or talking to a database. Now if all you want to do is send a Location: header, and have apache write to the access_log, then you might want to start rewriting some of your scripts as mod_perl handlers. Here's another way to look at Hits/sec as being bad to focus on. Let's say you have something that is 1000/sec and something that is 2000/sec, that's only .0005 different. Most of the time that .0005 is negligible compared to the time you will spend in the executing part of the application, which lets say is .01 in execution time, now the overall execution time is .0110 and .0105 which is 91/sec vs. 95/sec respectively. So what looked like something to be twice as fast is now only 4% faster. But if you write some little fast code, then it can make all the difference in the world. The reason I like Hello World, is that it lets me know the fastest I can go in that app, but there's no guarantees I'll get there. :) --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Using mod_perl handlers for max speed?
[EMAIL PROTECTED] (Philip Mak) wrote: Does this mean that if there's a heavily used script on my system that needs to be VERY fast, then it may be worth making it into a mod_perl handler? What are the caveats of using mod_perl handlers instead of normal scripts? The basic idea is this: with a handler, you're adding new capabilities to the server itself. With a script (CGI or Registry or otherwise), your functionality becomes a resource outside the server, and the server must check that resource, manage it, and cater to its interface needs. How aggressively the server manages reloading, etc. varies from one scheme to another, but that additional stuff is the reason Registry scripts are usually slower than handlers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Dynamic httpd.conf file using mod_perl...
On Mon, 16 Apr 2001, Jim Winstead wrote: [...] you would have to do a "run config template expander HUP" instead of just doing a HUP of the apache parent process, but that doesn't seem like a big deal to me. And it has the big advantage of also working with httpd's without mod_perl. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 70M impressions per day, http://valueclick.com
Re: Dynamic httpd.conf file using mod_perl...
At 04:16 AM 4/17/01, Ask Bjoern Hansen wrote: On Mon, 16 Apr 2001, Jim Winstead wrote: [...] you would have to do a "run config template expander HUP" instead of just doing a HUP of the apache parent process, but that doesn't seem like a big deal to me. And it has the big advantage of also working with httpd's without mod_perl. like proxy servers ... Going off on a slight tangent from the orginal topic - the template-based approach would also work well for subsystems that have separate configuration files - we put quite a bit of application configuration info into files other than httpd.conf, so that we can modify it without requiring a server restart. -Simon - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 70M impressions per day, http://valueclick.com
Dynamic httpd.conf file using mod_perl...
I work for a small domain hosting company, and we currently host a few
hundred domains. What I'm trying to do is have apache build the httpd.conf
file dynamically when it starts from a MySQL database. Easy enough. Got
most of it working, the only thing I'm running into is mod_rewrite problems.
Does anybody have any idea how to add the following:
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^90.0.0.1$
RewriteRule .* http://www.whatever.com
to my current perl code (note - this isn't extracting info from the database
yet. Just a simple text file for testing purposes):
Perl
open(SC, " /www/conf/virtual-domains.conf") || die "$!";
while(SC) {
chomp;
next if(/^s*#/);
my($sn,$sa,$ip,$htdir,$errlog,$translog) = split(/:/,$_,-1);
$VirtualHost{$sn} = {
ServerName = $sn,
ServerAlias = "www.".$sn",
DocumentRoot = "/www/virtual/".$htdir,
ErrorLog = "/www/virtual/".$htdir."logs/".$errlog,
TransferLog = "/www/virtual/".$htdir."logs/".$translog
};
}
close(SC);
__END__
/Perl
I'm thinking I can just add RewriteEngine = "on" to the VirtualHost hash.
But how do I handle the RewriteCond and the RewriteRule? Can I make a hash
of hashes or something? Maybe do something like:
RewriteCond = {'\%{REMOTE_ADDR}' = "!^90.0.0.1\$" },
RewriteRule = {'\.*' = "http://www.whatever.com" },
But that doesn't really work. Just so you know, I've removed all of the
error checking for readability. I didn't copy and paste this, so there
might be some syntax errors. Anyway, if anybody can make a suggestion, or
point me at a web site I would appreciate it. Thanks a ton in advance.
Brian Johnson
Systems Administrator/Programmer
Keweenet, LLC (www.keweenet.com)
Surgeon General announcement:
"Coffee is a direct substitute for sleep."
Re: Dynamic httpd.conf file using mod_perl...
What I'm trying to do is have apache build the httpd.conf file dynamically when it starts from a MySQL database. It might be easier and more bulletproof to build the conf file off-line with a simple perl script and a templating tool. We did this with Template Toolkit and it worked well. - Perrin
RE: Dynamic httpd.conf file using mod_perl...
It might be easier and more bulletproof to build the conf file off-line with a simple perl script and a templating tool. We did this with Template Toolkit and it worked well. - Perrin That would be fine and dandy, but it's not exactly what I'm going after. Currently if I want to make a change to all of our clients I have to go through and edit every config file (I have a .conf file for each domain and then use an Include in the httpd.conf). Using the mod_perl way I can change it once in the httpd.conf file, restart apache, and the change will take place for all the domains that are affected by the Perl /Perl code. Know what I mean? Brian Johnson Systems Administrator/Programmer Keweenet, LLC (www.keweenet.com) Surgeon General announcement: "Coffee is a direct substitute for sleep."
Re: Dynamic httpd.conf file using mod_perl...
On Mon, Apr 16, 2001 at 07:12:23PM -0400, Brian wrote: It might be easier and more bulletproof to build the conf file off-line with a simple perl script and a templating tool. We did this with Template Toolkit and it worked well. - Perrin That would be fine and dandy, but it's not exactly what I'm going after. it seems to me you're conflating your goal and your means of achieving it. Currently if I want to make a change to all of our clients I have to go through and edit every config file (I have a .conf file for each domain and then use an Include in the httpd.conf). Using the mod_perl way I can change it once in the httpd.conf file, restart apache, and the change will take place for all the domains that are affected by the Perl /Perl code. Know what I mean? this is certainly possible by generating your configuration files using a perl script, outside of using mod_perl. jim
RE: Dynamic httpd.conf file using mod_perl...
it seems to me you're conflating your goal and your means of achieving it. I don't think I'm conflating the goal and the means. At least I don't see how I am this is certainly possible by generating your configuration files using a perl script, outside of using mod_perl. Aaah, but you see that would create a bunch of configuration files or make one huge configuration file. My method would eliminate all but one configuration file (httpd.conf) and use our billing database to create the configuration files. That way when a client is deactivated in the DB it's automatically deactivated in apache the next time it's HUP'ed. Yeah, I could write a separate perl script to go in, find the line that says "Include /www/conf/viraul/domain.conf" and then pound it out and restart the server. I can also write a perl script to create all the config files for me. But why not do both in the config file if possible? It's all written, only problem is the mod_rewrite directives. Any ideas on how to do them in a Perl directive? Thanks in advance. Brian Johnson Systems Administrator/Programmer Keweenet, LLC (www.keweenet.com) Surgeon General announcement: "Coffee is a direct substitute for sleep."
Re: Dynamic httpd.conf file using mod_perl...
On Mon, Apr 16, 2001 at 07:37:32PM -0400, Brian wrote: it seems to me you're conflating your goal and your means of achieving it. I don't think I'm conflating the goal and the means. At least I don't see how I am well, perhaps that wasn't the best way to put it. this is certainly possible by generating your configuration files using a perl script, outside of using mod_perl. Aaah, but you see that would create a bunch of configuration files or make one huge configuration file. My method would eliminate all but one configuration file (httpd.conf) and use our billing database to create the configuration files. That way when a client is deactivated in the DB it's automatically deactivated in apache the next time it's HUP'ed. Yeah, I could write a separate perl script to go in, find the line that says "Include /www/conf/viraul/domain.conf" and then pound it out and restart the server. I can also write a perl script to create all the config files for me. But why not do both in the config file if possible? and the suggestion perrin made would have basically the same result. your configuration file would be a template, basically, that was expanded into the real configuration file that is then read by the apache process. it is very close to what you are doing, without introducing the vagaries of getting mod_perl and mod_rewrite to cooperate. you would have to do a "run config template expander HUP" instead of just doing a HUP of the apache parent process, but that doesn't seem like a big deal to me. It's all written, only problem is the mod_rewrite directives. Any ideas on how to do them in a Perl directive? Thanks in advance. nope. jim
Re: Dynamic httpd.conf file using mod_perl...
checkout the following link: http://www.geocrawler.com/archives/3/182/2000/3/0/3377287/ the search engine at: http://www.geocrawler.com/lists/3/Web/182/0/ is your friend. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Brian wrote: It's all written, only problem is the mod_rewrite directives. Any ideas on how to do them in a Perl directive? Thanks in advance.
Re: Dynamic httpd.conf file using mod_perl...
It might be easier and more bulletproof to build the conf file off-line with a simple perl script and a templating tool. We did this with Template Toolkit and it worked well. - Perrin That would be fine and dandy, but it's not exactly what I'm going after. Currently if I want to make a change to all of our clients I have to go through and edit every config file (I have a .conf file for each domain and then use an Include in the httpd.conf). Using the mod_perl way I can change it once in the httpd.conf file, restart apache, and the change will take place for all the domains that are affected by the Perl /Perl code. Know what I mean? Sure, and it looks like you got your question answered. The two approaches are pretty similar in terms of the results, but the off-line approach does require either using a custom startup script or doing two steps (build conf and then restart server). On the other hand, the off-line approach will allow you to start your server even when the database is down. You might want to build your dynamic conf file approach with a cache for the last-accessed database info, so that it has something to fall back to if the db goes down. - Perrin
RE: Dynamic httpd.conf file using mod_perl...
Thanks all for the suggestions and idea provoking chatter. I appreciate. I also much apologize as I didn't fully comprehend your first suggestion Perrin. Simple mind lapse caused by a lack of sleep and not enough caffeine. :o) But, you are right about the DB being down. A cache is a must in such a case. Thank you for pointing that out. :o) Brian Johnson Systems Administrator/Programmer Source1hosting.tv (www.source1hosting.tv) Surgeon General announcement: "Coffee is a direct substitute for sleep." Sure, and it looks like you got your question answered. The two approaches are pretty similar in terms of the results, but the off-line approach does require either using a custom startup script or doing two steps (build conf and then restart server). On the other hand, the off-line approach will allow you to start your server even when the database is down. You might want to build your dynamic conf file approach with a cache for the last-accessed database info, so that it has something to fall back to if the db goes down. - Perrin
site using mod_perl
Hi, I use mod_perl on http://www.a-blast.org/ and want to suggest it for http://perl.apache.org/sites.html It is a "truly interactive text network", written completely in mod_perl. For a quick, non-technical overview have a look on http://www.assoziations-blaster.de/prixars/ (its in english on our old domain). About one year ago, it runs on M$ IIS with ActivePerl and some PHP, in the meantime it is completely rewritten as Apache module, using MySQL as database. With this, I speed up the execution time from ~3 Seconds to ~10 milliseconds for each Blast-Page (OK, OK, the old machine had a very worst hardware, now we use only a semi-worst one: Pentium II 350, 320 MB RAM with Soft-RAID 0 under Linux). The blast_engine includes the links into the texts in realtime, also the statistics are created in realtime: http://www.a-blast.org/statistics/ http://www.assoziations-blaster.de/statistik/ (german, with much more traffic) The blaster uses the speed benefit of keeping the complete keyword list in memory (more then 5 MB for the german version), for the non-linear real-time linker I use a ~50 line regexp .-) The HTML-Files are compressed on-the-fly with Compress::Zlib, so we keep bandwidth (and transmission time to the users) small. so, hmmm, if you have any (technical?) questions, feel free to ask ;) The german version has about 5000 visitors and 2 page views per day, which is very good for a non-profit net.art project in germany. Ciao Alvar -- Alvar C.H. Freude | [EMAIL PROTECTED] Demo: http://www.online-demonstration.org/ | Mach mit! Blast-DE: http://www.assoziations-blaster.de/ | Blast-Dich-Fit Blast-EN: http://www.a-blast.org/ | Blast/english
Re: using mod_perl with SSI-run perl scripts
Ok, I have an update on this. I found some docs on how to set things up, but ran into a problem when compiling it. Here's the line I used to configure mod_perl, and have it build apache: perl Makefile.PL PERL_SSI=1 USE_APACI=1 APACI_ARGS='--prefix=/usr/apache --enable-shared=max --disable-shared=include --disable-shared=perl --enable-module=include' It builds fine, and seems to do what I want, until the 'make test' stage, which exits at: Failed Test Status Wstat Total Fail Failed List of failed --- modules/ssi.t?? ?? % ?? 9 tests skipped. httpd terminated httpd terminated *** Error code 9 Stop in /usr/src/www/mod_perl-1.24. Is there anything that I'm doing wrong?
Re: using mod_perl with SSI-run perl scripts
Hello , mod_perl will never reduce your server load (in fact it will increase it ) and specialy SSI+Modperl will bring you realy huge httpd procs . I think that you should read http://perl.apache.org/guide/performance.html http://perl.apache.org/guide/scenario.html best Constantin - Original Message - From: "Mike Hodson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 18, 2000 5:12 AM Subject: using mod_perl with SSI-run perl scripts Hello there. I am currently looking for a way to reduce the server load on a very popular website. I must admit, I am not a whiz with perl, nor was I the designer of our current system. The web content designer (I myself am a server administrator) is using a set of small perl scripts run thru the SSI !--exec CGI="/cgi-bin/banner.pl"-- method to change advertizing banners on different pages. I personally want to convert them into some sort of embperl or PHP code embedded into the pages, however the current number of pages that require these scripts number in the thousands, and I can't justify changing everything over if there is another option. I need to know if mod_perl can execute the perl scripts called by the exec cgi SSI command, and if so, instructions on how to make this work properly. Right now our server (p3-550mhz, 768 megs ram, freebsd 4.0) load average is steady around 5, and spikes to over 20 when people request the SSI enabled pages. Thanks in advance for any help on this subject. Regards, Mike Hodson
Re: using mod_perl with SSI-run perl scripts
"MH" == Mike Hodson [EMAIL PROTECTED] writes: MH administrator) is using a set of small perl scripts run thru the MH SSI !--exec CGI="/cgi-bin/banner.pl"-- method to change MH advertizing banners on different pages. I personally want to MH convert them into some sort of embperl or PHP You should use !--#include virtual="/cgi-bin/banner.pl" -- in preference to exec cgi. If you configure mod_perl to run /cgi-bin/banner.pl and make it mod_perl safe (see the guide on how to do that) it will "just work" (tm). You probably also want to offload any images and other static content to another server (possibly on the same host, but not a virtual server. it needs to be a separate instance of httpd without mod_perl). The guide goes into many techniques on performance tuning as well. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: using mod_perl with SSI-run perl scripts
"BC" == Bogomolnyi Constantin [EMAIL PROTECTED] writes: BC mod_perl will never reduce your server load (in fact it will increase it ) This is an absolutely wrong statement. When I converted one site to mod_perl, the load dropped dramatically because it could handle the requests faster. This allowed me to avoid buying additional hardware. Using the tuning tips I collected during that transition (now found as the mod_perl_tuning docs that come with mod_perl) I was able to reduce the load even more. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: using mod_perl with SSI-run perl scripts
Vivek Khera [EMAIL PROTECTED] writes: "BC" == Bogomolnyi Constantin [EMAIL PROTECTED] writes: BC mod_perl will never reduce your server load (in fact it will increase it ) This is an absolutely wrong statement. Depends where you're coming from, surely? If you're purely SSI, then you're adding overhead, if you're already heavily perl then you're reducing the load (provided you play by the rules ;-). -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: using mod_perl with SSI-run perl scripts
Depends where you're coming from, surely? If you're purely SSI, then you're adding overhead, if you're already heavily perl then you're reducing the load (provided you play by the rules ;-). This guy already said he was trying to replace #exec calls to perl CGI scripts, so it should definitely help him reduce load. - Perrin
using mod_perl with SSI-run perl scripts
Hello there. I am currently looking for a way to reduce the server load on a very popular website. I must admit, I am not a whiz with perl, nor was I the designer of our current system. The web content designer (I myself am a server administrator) is using a set of small perl scripts run thru the SSI !--exec CGI="/cgi-bin/banner.pl"-- method to change advertizing banners on different pages. I personally want to convert them into some sort of embperl or PHP code embedded into the pages, however the current number of pages that require these scripts number in the thousands, and I can't justify changing everything over if there is another option. I need to know if mod_perl can execute the perl scripts called by the exec cgi SSI command, and if so, instructions on how to make this work properly. Right now our server (p3-550mhz, 768 megs ram, freebsd 4.0) load average is steady around 5, and spikes to over 20 when people request the SSI enabled pages. Thanks in advance for any help on this subject. Regards, Mike Hodson
