Re: PerlAuthenHandler and ErrorDocument 401
Torsten Foertsch wrote: On Wed 21 May 2008, fof wrote: I have had problems before when mod_perl seems to override various behavior in Apache. For example when using a PerlAuthenHandler it seemed to wipe out the standard DirectoryIndex directive which the main webserver had set to index.htm etc. This caused a problem when visiting the root directory as it would not serve up the default index page. To fix this I had to add a PerlFixUpHandler which restored some default settings. A Perl authentication handler if correctly designed does not interfere with a DirectoryIndex. It should also work smoothly inside a Location or Directory block or from a .htaccess file. So I suspect your problem lies in the code of your handler. (Are you fiddling with $r-filename or depending on $r-location?) But without insight in that code I think nobody can help. Torsten Hi Torsten, Thanks again for your reply. You might be right, I am probably not doing things correctly although I don't believe I am doing anything fancy. I can't see where I might be fiddling with the objects you mentioned. I have uploaded my MyAuthenHandler.pm and the modules it relies on for configuration perhaps if you have time you could peruse the code and let me know if I am doing anything wrong for this type of operation. Thanks again for your help on this. http://www.nabble.com/file/p17356582/MyAuthenHandler.pm MyAuthenHandler.pm http://www.nabble.com/file/p17356582/MyModPerlUtility.pm MyModPerlUtility.pm http://www.nabble.com/file/p17356582/MyModPerlDBUtility.pm MyModPerlDBUtility.pm -- View this message in context: http://www.nabble.com/PerlAuthenHandler-and-ErrorDocument-401-tp17330888p17356582.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Current working directory always /
Hello, It took me hours just to notice that my current working directory of mod_perl2 always appear as / Alias /modperl/ /var/www/modperl/ Location /modperl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all /Location But either I place my script at /var/www/modperl/test.pl OR /var/www/modperl/directory/test.pl use CGI qw(:standard); print header; use Cwd; print getcwd(); These always print out /. I have some modules living in my working directory how can I have the directory working as like no using the mod_perl2 before ? Thanks
Re: Current working directory always /
william wrote: Hello, It took me hours just to notice that my current working directory of mod_perl2 always appear as / See slide 77 and on: http://gozer.ectoplasm.org/Talks/mod_perl-2.0-from-cgi-fast.pdf Specifically slide 81 looks like it addresses this issue. Try adding: require “/var/www/modperl/directory/test.pl; to your cgi script. Hope that helps. Alias /modperl/ /var/www/modperl/ Location /modperl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all /Location But either I place my script at /var/www/modperl/test.pl OR /var/www/modperl/directory/test.pl use CGI qw(:standard); print header; use Cwd; print getcwd(); These always print out /. I have some modules living in my working directory how can I have the directory working as like no using the mod_perl2 before ? Thanks -- Red Hot Penguin Consulting LLC mod_perl/PostgreSQL consulting and implementation http://www.redhotpenguin.com/
Re: Current working directory always /
On Wed, May 21, 2008 at 4:29 PM, Fred Moyer [EMAIL PROTECTED] wrote: william wrote: Hello, It took me hours just to notice that my current working directory of mod_perl2 always appear as / See slide 77 and on: http://gozer.ectoplasm.org/Talks/mod_perl-2.0-from-cgi-fast.pdf Specifically slide 81 looks like it addresses this issue. Try adding: require /var/www/modperl/directory/test.pl; to your cgi script. Hope that helps. Alias /modperl/ /var/www/modperl/ Location /modperl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all /Location But either I place my script at /var/www/modperl/test.pl OR /var/www/modperl/directory/test.pl use CGI qw(:standard); print header; use Cwd; print getcwd(); These always print out /. I have some modules living in my working directory how can I have the directory working as like no using the mod_perl2 before ? Thanks -- Red Hot Penguin Consulting LLC mod_perl/PostgreSQL consulting and implementation http://www.redhotpenguin.com/ Thanks, I also found the same and better solution using ModPerl::RegistryPrefork http://perl.apache.org/docs/2.0/api/ModPerl/RegistryPrefork.html I don't know why they don't just recommend using ModPerl::RegistryPrefork instead of ModPerl::Registry , that could save a lot of other people's trouble. But there must be a reason that I don't know. Thanks.
Re: Current working directory always /
On Wed 21 May 2008, william wrote: I don't know why they don't just recommend using ModPerl::RegistryPrefork instead of ModPerl::Registry , that could save a lot of other people's trouble. But there must be a reason that I don't know. because it won't work with a threaded MPM. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: Current working directory always /
On Wed, May 21, 2008 at 5:26 PM, Torsten Foertsch
[EMAIL PROTECTED] wrote:
On Wed 21 May 2008, william wrote:
I don't know why they don't just recommend using
ModPerl::RegistryPrefork instead of ModPerl::Registry , that could
save a lot of other people's trouble. But there must be a reason that
I don't know.
because it won't work with a threaded MPM.
Torsten
--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]
Sigh...Even ModPerl::RegistryPrefork does not work as what I want, why
do they say Run unaltered CGI scripts under mod_perl when it is
working differently with CGI ?
/var/www/modperl/Dir/Test.pm
package Dir::Test;
use Cwd;
use Storable;
sub mygetcwd()
{
open(FILE, 'textfile') || die $!; #No such file or directory at
/var/www/modperl//Dir/Test.pm line 8.\n
print FILE;
print cwd; #The result is /var/www/modperl
}
1;
/var/www/modperl/Dir/textfile
Hello world
/var/www/modperl/test.pl
use CGI qw(:standard);
print header;
use Dir::Test;
Dir::Test::mygetcwd();
Because the working directory is always the directory of the start of
execution file /var/www/modperl .So why can't I use the relative
directory , it only works if I use open(FILE, 'Dir/textfile');
Thanks.
Re: Current working directory always /
On Wed, May 21, 2008 at 7:52 AM, william [EMAIL PROTECTED] wrote: Sigh...Even ModPerl::RegistryPrefork does not work as what I want, why do they say Run unaltered CGI scripts under mod_perl when it is working differently with CGI ? /var/www/modperl/Dir/Test.pm package Dir::Test; Under normal CGI, the cwd will be the directory that the script was found in, not the directory of the currently executing module. This is the same behavior. - Perrin
Re: Current working directory always /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
william wrote:
| /var/www/modperl/Dir/Test.pm
| package Dir::Test;
|
| use Cwd;
| use Storable;
|
| sub mygetcwd()
| {
| open(FILE, 'textfile') || die $!; #No such file or directory at
| /var/www/modperl//Dir/Test.pm line 8.\n
| print FILE;
| print cwd; #The result is /var/www/modperl
| }
|
| 1;
You should almost always use full paths to files, think of threads.
- --
-
Philip M. Gollucci ([EMAIL PROTECTED])
o:703.549.2050x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.8 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFINDFwdbiP+9ubjBwRArraAJ4gIWKyxD17Yiqjn71FRF4jOGicPACdFd6F
kZWFcNaE/JkhSjcldojVrQY=
=XfnH
-END PGP SIGNATURE-
Re: Current working directory always /
On Wed, May 21, 2008 at 10:28 AM, Philip M. Gollucci [EMAIL PROTECTED] wrote: You should almost always use full paths to files, think of threads. This is true in a module you plan to distribute on CPAN, but for local use you typically don't need to think of threads because most people will not use them. There are arguments you could make that full paths increase security though. - Perrin
is there a maximum output character length ?
Hello, I am just so tired after hours of debugging, why does is never
write text into the file completely ? It has not problem if using CGI.
Let's say if I have
$ruleStr = aa eee;
open(PARSER,$self-{parser}.pm);
print PARSER $ruleStr;
It will write a few characters only, not complete. Is there a thread
problem or something ?
Thanks
Re: is there a maximum output character length ?
william wrote:
Let's say if I have
$ruleStr = aa eee;
open(PARSER,$self-{parser}.pm);
print PARSER $ruleStr;
It will write a few characters only, not complete. Is there a thread
problem or something ?
You need to explicitly close the file - under CGI, your program exits at
the end of the request and will close any open files. Under mod_perl it
will leave the files open.
Addclose(PARSER)after you finish writing the file - this isn't a
mod_perl thing, it's just good programming practice.
John
Re: is there a maximum output character length ?
On Thu, May 22, 2008 at 4:30 AM, John ORourke [EMAIL PROTECTED] wrote:
william wrote:
Let's say if I have
$ruleStr = aa eee;
open(PARSER,$self-{parser}.pm);
print PARSER $ruleStr;
It will write a few characters only, not complete. Is there a thread
problem or something ?
You need to explicitly close the file - under CGI, your program exits at the
end of the request and will close any open files. Under mod_perl it will
leave the files open.
Addclose(PARSER)after you finish writing the file - this isn't a
mod_perl thing, it's just good programming practice.
John
Omg, I love you John, lol. Haha, I had spent at lease 3 hours for
this, why is it so in mod_perl ?
Thanks.
Re: is there a maximum output character length ?
william wrote: On Thu, May 22, 2008 at 4:30 AM, John ORourke [EMAIL PROTECTED] wrote: william wrote: It will write a few characters only, not complete. Is there a thread problem or something ? You need to explicitly close the file - under CGI, your program exits at the end of the request and will close any open files. Under mod_perl it will leave the files open. Omg, I love you John, lol. Haha, I had spent at lease 3 hours for this, why is it so in mod_perl ? Well thanks! Under regular CGI, every time your browser requests a page, Apache has to find your script, load Perl, compile your script and any modules you use, run it, and exit Perl. Under mod_perl, all the loading and compiling is done when Apache starts, not on every request - it's doing far less work. There's a lot of good info on http://perl.apache.org/ but I know what it's like when you're too busy debugging to RTFM :) John
Re: is there a maximum output character length ?
On Thu, May 22, 2008 at 4:50 AM, John ORourke [EMAIL PROTECTED] wrote: william wrote: On Thu, May 22, 2008 at 4:30 AM, John ORourke [EMAIL PROTECTED] wrote: william wrote: It will write a few characters only, not complete. Is there a thread problem or something ? You need to explicitly close the file - under CGI, your program exits at the end of the request and will close any open files. Under mod_perl it will leave the files open. Omg, I love you John, lol. Haha, I had spent at lease 3 hours for this, why is it so in mod_perl ? Well thanks! Under regular CGI, every time your browser requests a page, Apache has to find your script, load Perl, compile your script and any modules you use, run it, and exit Perl. Under mod_perl, all the loading and compiling is done when Apache starts, not on every request - it's doing far less work. There's a lot of good info on http://perl.apache.org/ but I know what it's like when you're too busy debugging to RTFM :) John Yeah, I have read a lot of those things that you wrote many times in peal.apache.org but I just don't know what is the specific relation to why it never write the file completely ! Thanks.
Re: [OT] is there a maximum output character length ?
Well thanks! Under regular CGI, every time your browser requests a page, Apache has to find your script, load Perl, compile your script and any modules you use, run it, and exit Perl. Under mod_perl, all the loading and compiling is done when Apache starts, not on every request - it's doing far less work. There's a lot of good info on http://perl.apache.org/ but I know what it's like when you're too busy debugging to RTFM :) Yeah, I have read a lot of those things that you wrote many times in peal.apache.org but I just don't know what is the specific relation to why it never write the file completely ! It's just how operating systems work - to speed things up, when you write to the file you're actually writing to a buffer in memory. When the buffer gets full (usually a few kB), the operating system will write it all out to the disk. If you close the file, it will also write it all out the disk. It's simply good practice to tidy up before you quit your program - previously you were relying on perl to do this for you, because it's good like that. cheers John @ list, ! $| ;) --
Re: [OT] Solaris + Apache 2.2 / PHP 5 cluster config help
On May 20, 2008, at 4:00 PM, Issac Goldstand wrote: Right - I know that in theory, but was worried about the disk/ram/ cpu overhead of replicating the writes to all of the slave servers offsetting that benefit... The explanation i gave to this on the Pylons list today was such: when you're successful, you cluster to a couple of servers with replication when you're SUCCESSFUL!!, you cluster to a handful of servers with replication and horizontal partitioning you honestly shouldn't have an issue with writes/reads until you have a hugely utilized service you can also do psuedo-partitioning to make things work faster-- keep 1 DB + replication system for your app's business logic ( accounts, meta data, etc) split out your sessions and logging facilities (if any) to a seperate box(es). those write on every request - just give them entirely different boxes databases to save to, and free up the write/read/replication structure for your data personally, i think one should always architect applications with separate DB handles for read/write/log/session at the outset. you can essentially make them 'one' handle until necessary... but it takes barely any time to program with that paradigm from the start... vs trying to retrofit in clustering to an app when its too late. my bigger questoin on your design would be this: why are you using apache? off your setup, you don't seem to suggest any need for apache. i think you'd be MUCH better off using nginx/lighttpd with fastCGI . Have you tried using APC ( http://pecl.php.net/package/APC ) ? I know it used to suck ass. IIRC , APC used to be worthless and eAccelerator was the only thing that worked - and was great. then APC was working, and eAccelerator kicked its ass. but then eAccelerator broke for like 10 months, and APC worked - so it picked up a lot of steam. looking at your specs, i'd toss as much ram on your http machines as money allows, run nginx + fastcgi on the boxes. give fcgi some generour ram and APC .5GB. then run the rest of the box on memcached. its not worth running replicants on your http machines - you're better off tossing the CPU to php and the RAM to memcached. // Jonathan Vanasco w. http://findmeon.com/user/jvanasco e. [EMAIL PROTECTED] | Founder/CEO - FindMeOn, Inc. | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Privacy Minded Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: [OT] is there a maximum output character length ?
If you have a reason to leave it open, you can always set autoflush on the file. open FO, file_out; my $was = select FO; local $| = 1; select $was; print FO a; print FO b; etc. 2008/5/21 John ORourke [EMAIL PROTECTED]: Well thanks! Under regular CGI, every time your browser requests a page, Apache has to find your script, load Perl, compile your script and any modules you use, run it, and exit Perl. Under mod_perl, all the loading and compiling is done when Apache starts, not on every request - it's doing far less work. There's a lot of good info on http://perl.apache.org/ but I know what it's like when you're too busy debugging to RTFM :) Yeah, I have read a lot of those things that you wrote many times in peal.apache.org but I just don't know what is the specific relation to why it never write the file completely ! It's just how operating systems work - to speed things up, when you write to the file you're actually writing to a buffer in memory. When the buffer gets full (usually a few kB), the operating system will write it all out to the disk. If you close the file, it will also write it all out the disk. It's simply good practice to tidy up before you quit your program - previously you were relying on perl to do this for you, because it's good like that. cheers John @ list, ! $| ;) -- -- Dodger
Re: PerlAuthenHandler and ErrorDocument 401
Philip M. Gollucci wrote: In my experience and a few others on the list if you search the archives, its almost never worth it to override Location / with something unless you don't have any 'assets' being served from this server which is an advisable idea. Thanks for your response Philip although I am not 100% sure I understand what you are getting at here. Are you suggesting that one should not use Location because I am trying to serve a HTML document on a 401? is this what you mean by an 'asset'? Philip M. Gollucci wrote: Anyway, I think what you are after might be a fully baked AAA (3 httpd phases) More examples are on perl.apache.org My module works? Am i missing a phase in what I am doing here? Thanks for all your help BTW. -- View this message in context: http://www.nabble.com/PerlAuthenHandler-and-ErrorDocument-401-tp17330888p17397588.html Sent from the mod_perl - General mailing list archive at Nabble.com.
