How to get VirtualHostUser abc/VirtualHost
I have a PerlTransHandler and I have a bunch of virtual hosts. Each virtual host looks like this VirtualHost abc.com User abc Group abcs /VirtualHost (How) can I access the User and Group definitions in the VirtualHost (which are intended for suexec)? Is this feature missing in mod_perl 1.24? The eagle book only knows on mod_perl 1.19. ...darko
Re: How to get VirtualHostUser abc/VirtualHost
I have a PerlTransHandler and I have a bunch of virtual hosts. Each virtual host looks like this VirtualHost abc.com User abc Group abcs /VirtualHost (How) can I access the User and Group definitions in the VirtualHost (which are intended for suexec)? Is this feature missing in mod_perl 1.24? The eagle book only knows on mod_perl 1.19. You can use $r-server-uid and $r-server-gid, these were added in 1.21_01. -- Eric
The Eagle has landed!
I am trying to work my way through Stein and MacEachern but having a few
teething troubles.
I am following the example code in Chapter 2 faithfully, have build and
installed mod_perl
(which now appears under httpd -l) and modified the configuration files
according to the suggestions in the book. ie:
Perl 5.6.0
Apache 1.3.12
mod_perl-1.24
ServerRoot is /usr/local/apache
underneath which I have created the lib/perl/Apache tree for holding
mod_perl modules,
and dutifully entered the required code in a file called Hello.pm in this
directory.
DocumentRoot is /usr/local/apache/htdocs
in httpd.conf I have added the following:
--
IfModule mod_perl.c
Include conf/perl.conf
/IfModule
--
conf/perl.conf looks like this:
--
PerlRequire conf/startup.pl
PerlFreshRestart On
Location /hello/world
SetHandler perl-script
PerlHandler Apache::Hello
/Location
---
and startup.pl looks like this:
---
#!/usr/local/bin/perl
print "\n\tstartup.pl is attempting to modify the include path...\n\n";
BEGIN {
use Apache();
use lib Apache-server_root_relative('lib/perl');
}
use Apache::Registry
use Apache::Constants
use CGI qw(-compile :all);
use CGI::Carp;
1;
--
which I understood was going to update @INC to include my new module
library, and the Location /hello/world directive would realise that
Apache::Hello refered to ServerRoot/lib/perl/Apache/Hello.pm...
However, when attempting to access http://localhost/hello/world from a
browser it returns 404, and the errorlog shows the /hello/world URL appended
to DocumentRoot, so of course it can't find anything, it's expecting to find
a DocumentRoot/hello/world! Clearly I have misunderstood something here
but the Apache manual assures me that arguments to Location
are completely independent of the file system... any ideas?
Thanks,
Greg
Re: Interfacing from Apache to Access
Lorenzo Gordon wrote: Hello, I am a software developer for The London School of Hygiene Tropical Medicine, UK. My query is the following: I have been able to successfully run a Perl script from MS-DOS that would pull out the necessary info. from an Access database I wrote last year (Access 97). The problem is that in order to get the script to talk to the web pages i am currently designing, the script must run on the School's network, which is a Unix Solaris machine running Apache. Both the School's Web Administrator have been struggling (and so far failing) to find an ODBC-like driver that will enable Unix to talk to Access via my Perl script. The implications of not been able to create some connection between these various componenets are massive. Any solutions/pointers/advice anyone might have would be greatly appreciated. I can't believe I'm the first person to have come across this problem! Please respond either to [EMAIL PROTECTED] . TIA, Lorenzo Gordon. You should probably think about converting your Access database to SQL Server. Access is not a good choice for a production server, nor will it ever be, since Micros~1 wants to keep selling SQL Server. Look at some of the old threads about interfacing to SQL Server for more information. Having said this, I'll assume that there are powerful forces beyond your control that make it impossible to shitcan Access. So, here's something that will work, as long as your traffic load is light. Write a simple socket interface to connect Apache Perl to your existing Windoze Perl script (which you'll hack to set up as a simple server). Invent your own protocol. Locking issues will come up, but you can manage this yourself with a little creativity. There are pretty good examples of how to do simple socket things with Perl, in the Perl books. HTH.
Re: Interfacing from Apache to Access
From: Eric Strovink [EMAIL PROTECTED] wrote: Write a simple socket interface to connect Apache Perl to your existing Windoze Perl script (which you'll hack to set up as a simple server). Invent your own protocol. Locking issues will come up, but you can manage this yourself with a little creativity. There are pretty good examples of how to do simple socket things with Perl, in the Perl books. This has already been done! See DBD::Proxy. This allows you to run a little perl Program on the machine with the Access DB which acts as a proxy DB server, then the client uses DBD::Proxy (as opposed to DBD::Oracle or whatever) to access the database. Never tried it myself, but it sounds cool! * Dave Mitchell, Operations Manager, * Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED] * Tel: +44 114 281 6113.The usual disclaimers * * Standards (n). Battle insignia or tribal totems
Re: Interfacing from Apache to Access
DBD::Proxy does work the way you describe it. I've used it with succes to address MSSQL DBs. So far, with Access I met a few difficulties with memos (Access' BLOBs), but maybe I didn't find the way to do it. Fabrice David Mitchell wrote: From: Eric Strovink [EMAIL PROTECTED] wrote: Write a simple socket interface to connect Apache Perl to your existing Windoze Perl script (which you'll hack to set up as a simple server). Invent your own protocol. Locking issues will come up, but you can manage this yourself with a little creativity. There are pretty good examples of how to do simple socket things with Perl, in the Perl books. This has already been done! See DBD::Proxy. This allows you to run a little perl Program on the machine with the Access DB which acts as a proxy DB server, then the client uses DBD::Proxy (as opposed to DBD::Oracle or whatever) to access the database. Never tried it myself, but it sounds cool! * Dave Mitchell, Operations Manager, * Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED] * Tel: +44 114 281 6113.The usual disclaimers * * Standards (n). Battle insignia or tribal totems
Perl CGI/Mod_perl testing - HeLp!
Hello all, I could use your assistance. I have been tasked to show the performance differences between Perl CGI scripts and mod_perl scripts running on an Apache web server on a small isolated network. I am assuming mod_perl will outperform CGI if the scripts are well written. I need to send these scripts to Apache so that it can run them. From this I can then generate some statistics as to how well each of them performs. I am not sure where to begin in regards to the network aspect of the testing. I have been reading the Apache/mod_perl FAQ/How-To's on the net and studying Perl from O' Reilly's Learning Perl and Perl Programming. I understand that if the Apache server is running: # apachectl start -- starts Apache # ps -ef | grep httpd -- starts about 10 httpd processes by default to handle connections Then I evoke a Perl CGI script on the same system: # perl cgi_test.pl -- the external Perl interpretor processes the script and passes it to the Apache web server to be parsed. * I do not know how to proceed in getting a script that originated from a client to execute on the Apache webserver? Do I need to specify an IP address in the script or configure a configuration file? * The script would also have to execute many thousands of times for better results. * I am assuming that after I compile the mod_perl binaries so that the Apache server supports mod_perl, it will still support Perl CGI??? The testing is being done primarily on Mandrake Linux 7.0 for now but I may do the same thing for Win98se. The Apache and mod_perl distros are new within a month. Anyone have any good ideas on how to go about doing this??? Thanks a bunch. NETWORK CONFIGURATION Gateway machine (Win98se) = 192.168.0.1 Apache webserver (Mandrake 7.0/Win98se/Sol 7) = 192.168.0.2 Test client (Win98/Mandrake 7.0) = 192.168.0.3 Sincerely, Rich
Re: Interfacing from Apache to Access
On Tue, 11 Jul 2000 14:52:58 +0100 (BST), David Mitchell wrote: From: Eric Strovink [EMAIL PROTECTED] wrote: Write a simple socket interface to connect Apache Perl to your existing Windoze Perl script (which you'll hack to set up as a simple server). Invent your own protocol. Locking issues will come up, but you can manage this yourself with a little creativity. There are pretty good examples of how to do simple socket things with Perl, in the Perl books. This has already been done! See DBD::Proxy. This allows you to run a little perl Program on the machine with the Access DB which acts as a proxy DB server, then the client uses DBD::Proxy (as opposed to DBD::Oracle or whatever) to access the database. Never tried it myself, but it sounds cool! I use it regularly, and it works fine ... Not good for heavy use, but for the 3-4 times a month it gets used in production, it works perfectly okay. Brgds, Mike.
Why mod_perl does not like File::Recurse module?
Could you explain the following I have a little script and run it from command line and in mod_perl #!/usr/bin/perl -w use CGI qw(:standard); use File::Tools; print header, start_html, p( "File::Copy::copydir ", defined File::Copy::copydir ? "ok" : "failed" ), p( "File::Recurse::recurse ", defined File::Recurse::recurse ? "ok" : "failed" ), end_html; From command line all is ok HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse ok/P/BODY/HTML In mod_perl I have the the different result HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse failed/P/BODY/HTML Why mod_perl does not like File::Recurse module??? -- ab ICQ: 3959207
Re: Is variable initialization necessary?
Barrie,
Thanks for the interesting benchmarks. In my case, I am only
initializing to '' or 0 to avoid warnings (I have PerlWarn On). What was
most interesting is the hit when you initialize an empty array. I'll
probably just continue on my current course, but the numbers are very
intriguing.
Thanks again.
Drew
Barrie Slaymaker wrote:
Drew Taylor wrote:
Does anyone have good evidence either way?
I don't see how Csub { my $foo ; ... could ever fail to undef $foo, modulo
bugs in perl. A hell of a lot of code wouldn't work, then.
My practice is to never init lexicals to undef/(), and only to '' or 0 if
they might be used before being set to a defined value. Can't see any
reason to = () in perl, where it's set to undef. C's a different question,
where you often get randomish values instead of perl's nice clean undef.
Side note: stay away from the dreaded Cmy $f = blah if blurgh idiom
unless you really understand it and really need it.
Below are some useless benchmarks. The first focuses on the performance of
Cmy $foo=(), the second is an attempt to put it in perspective. Both
on perl 5.6.0. It's a lot slower to initialize (66%). My take is that
it's a minor hit compared to the other things you're usually doing, unless
you do it in a tight inner loop.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Severe problem with $r-log_error
Hi,
I have a serious problem with the logging facility of MOD_PERL.
Something that once worked perfectly well suddenly turned quite.
I have tried all the logging statements from the eagle book, but
my error log file refuses to show any trace thereof.
I have also set the LogLevel to debug, but even with the following
I do not succeed:
my $rlog = $r-log;
$rlog-error('Message I try to print out');
nor with any of the following:
$r-log_error($msg);
$r-log-error($msg);
Not even a $r-log-debug(); works.
Only a brute warn() leaves a trace.
This is the identification of my server:
Apache/1.3.12 (Unix) PHP/3.0.16 mod_perl/1.24 mod_ssl/2.6.4
OpenSSL/0.9.5a
Help would be very appreciated.
Axel Wagner
--
Biobase GmbH -Mascheroder Weg 1B- D-38114 Braunschweig
phone: +49531/2603610 fax:+49531/2603670
eMail: [EMAIL PROTECTED] http://www.biobase.de
RE: Severe problem with $r-log_error
did you compile mod_perl with EVERYTHING=1 or PERL_LOG_API=1
--Geoff
-Original Message-
From: Axel Wagner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 11:30 AM
To: [EMAIL PROTECTED]
Subject: Severe problem with $r-log_error
Hi,
I have a serious problem with the logging facility of MOD_PERL.
Something that once worked perfectly well suddenly turned quite.
I have tried all the logging statements from the eagle book, but
my error log file refuses to show any trace thereof.
I have also set the LogLevel to debug, but even with the following
I do not succeed:
my $rlog = $r-log;
$rlog-error('Message I try to print out');
nor with any of the following:
$r-log_error($msg);
$r-log-error($msg);
Not even a $r-log-debug(); works.
Only a brute warn() leaves a trace.
This is the identification of my server:
Apache/1.3.12 (Unix) PHP/3.0.16 mod_perl/1.24 mod_ssl/2.6.4
OpenSSL/0.9.5a
Help would be very appreciated.
Axel Wagner
--
Biobase GmbH -Mascheroder Weg 1B- D-38114 Braunschweig
phone: +49531/2603610 fax:+49531/2603670
eMail: [EMAIL PROTECTED] http://www.biobase.de
RE: RE: Severe problem with $r-log_error
Geoff wrote: did you compile mod_perl with EVERYTHING=1 or PERL_LOG_API=1 Yes! And with a lot of other options. Take a look: content of .makepl_args.mod_perl: EVERYTHING=1 APACHE_SRC=../../../Server/apache_1.3.12/src NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 USE_DSO=1 PERL_DEBUG=1 PERL_TRACE=1 Axel -- Biobase GmbH -Mascheroder Weg 1B- D-38114 Braunschweig phone: +49531/2603610 fax:+49531/2603670 eMail: [EMAIL PROTECTED] http://www.biobase.de
RE: RE: Severe problem with $r-log_error
On Tue, 11 Jul 2000, Axel Wagner wrote: Geoff wrote: did you compile mod_perl with EVERYTHING=1 or PERL_LOG_API=1 Yes! And with a lot of other options. Take a look: content of .makepl_args.mod_perl: EVERYTHING=1 APACHE_SRC=../../../Server/apache_1.3.12/src NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 USE_DSO=1 PERL_DEBUG=1 PERL_TRACE=1 Next question, did you "use Apache::Log;" ? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
using a 3-tier mod_perl setup
I am running a 3-tier mod_perl setup as advised by the Guide:
Lightweight apache - mod_perl apache - db server.
One of the problems with this setup is that the mod_perl apache no longer
knows some details about the client request, like the client IP.
I used Ask Bjoern Hansen's module proxy_add_forward, which adds a
"X-Forwarded-For" header to to the request as it is forwarded to the
mod_perl apache server.
After I added SSL to my lightweight (but gaining!) apache, I found
I needed some SSL connection information on the mod_perl server as well.
I recently fell in love with mod_rewrite, and so I ported some of its
capabilities to mod_headers
The attached patch
(cd apache_1.3.XX; patch -p1 ProxyHeaderRewrite.patch; make install)
will add two commands to mod_headers:
HeaderRewrite - dynamically set headers for the client
ProxyHeaderRewrite - dynamically set headers for the upstream proxy server
While the original mod_headers would allow you so say:
Header append Foo "burfl"
Now you can say
HeaderRewrite append Foo "%{ENV:BURFL}", using the full RewriteCond syntax
My current lightweight apache server config looks something like:
ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
ProxyHeaderRewrite append X-Frontend-Host "%{HTTP_HOST}"
VirtualHost _default_:443
...
SSLOptions StdEnvVars
ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL} %{ENV:SSL_CIPHER}"
/VirtualHost
Did I miss another way to do this? Is this patch useful?
BTW,
the Guide on server architecture:
http://perl.apache.org/guide/strategy.html
Ask Bjoern Hansen's module proxy_add_forward
http://www.cpan.org/authors/id/ABH/mod_proxy_add_forward.c
-Tim
--- apache_1.3.12.dist/src/modules/standard/mod_headers.c Wed Oct 27 09:26:53
1999
+++ apache_1.3.12/src/modules/standard/mod_headers.cTue Jul 11 00:38:26 2000
@@ -99,9 +99,52 @@
* To remove a header:
* Header unset Author
*
+ *
+ * Non-standard Additions:
+ *
+ *Most code is from mod_rewrite, by
+ * Ralf S. Engelschall
+ * [EMAIL PROTECTED]
+ *Assembled by Tim Bishop [EMAIL PROTECTED]
+ *
+ *
+ * HeaderRewrite (set headers to client using RewriteCond syntax)
+ *
+ * Syntax: HeaderRewrite action header rewriteValue
+ *
+ * This works the same as the header directive, except that full
+ * mod_rewrite RewriteCond interpolation is performed on the rewriteValue
+ * string. See http://www.apache.org/docs/mod/mod_rewrite.html#RewriteCond
+ * (Of course, back-references (%N, $N) have no meaning)
+ *
+ *
+ * ProxyHeaderRewrite (set headers sent to upstream servers (if proxying))
+ *
+ * Syntax: ProxyHeaderRewrite action header rewriteValue
+ *
+ * ProxyHeaderRewrite allows you to rewrite headers sent to upstream
+ * servers when your server is functioning as a proxy server.
+ * This is useful when you want to send additional header information
+ * to upstream servers.
+ *
+ * Bugs: Cannot rewrite the Host header with ProxyHeaderRewrite
+ *
+ * Examples:
+ *
+ *# tell upstream server the ip of the request
+ *ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
+ *# tell upstream server info on SSL status
+ *VirtualHost _default_:443
+ *SSLOptions StdEnvVars
+ *ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL}
+%{ENV:SSL_CIPHER}"
+ */VirtualHost
+ *# tell upstream server the virtual host used
+ *ProxyHeaderRewrite append X-Frontend-Host "%{HTTP:Host}"
+ *
*/
#include "httpd.h"
+#include "http_log.h"
#include "http_config.h"
typedef enum {
@@ -111,12 +154,50 @@
hdr_unset = 'u' /* unset header */
} hdr_actions;
+typedef enum {
+ hdr_string = 's', /* header is a string */
+ hdr_env_var = 'v', /* set header from env var */
+ hdr_interpolate = 'i' /* header needs to be interpolated (not yet!) */
+} hdr_value_type;
+
+typedef enum {
+ hdr_client = 'c', /* modify headers for client */
+ hdr_upstream = 'u'/* modify headers for upstream server */
+} hdr_header_target;
+
typedef struct {
-hdr_actions action;
-char *header;
-char *value;
+ hdr_actions action;
+ char *header;
+ char *value;
+ hdr_value_type value_type;
+ hdr_header_target header_target; /* one of hdr_client | hdr_upstream */
} header_entry;
+
+/* env variable interpolation support */
+static void expand_variables_inbuffer(request_rec *r, char *buf, int buf_len);
+static char *expand_variables(request_rec *r, char *str);
+static char *lookup_variable(request_rec *r, char *var);
+static char *lookup_header(request_rec *r, const char *name);
+
+#ifndef LONG_STRING_LEN
+#define LONG_STRING_LEN 2048
+#endif
+
+/* REMOTE_NAME returns the hostname, or the dotted quad if the
+ * hostname lookup fails. It will force a DNS lookup according
+ * to the
Best book
Any ideas on which is the best book available out there for mod_perl?
RE: Session Cookies:cant retrieve value
Hi all, On Fri, 30 Jun 2000, Geoffrey Young wrote: From: darren chamberlain Maybe I stole it unconsciously... Sorry Geoff... feel free Somebody once said "Imitation is the sincerest form of flattery". Blessed if I can remember who it was. 73, Ged.
Re: Newbie: make test failure!
Hi there, On Fri, 7 Jul 2000, Michael Robinton wrote: On Sat, 8 Jul 2000, Greg Leidreiter wrote: but when I run 'make test' httpd listening on port 8529 letting apache warm up...\c still waiting for server to warm up.not ok I always get that error. I always ignore the error and everything seems to work fine. Running `make test' successfully is IMPORTANT! Please try to find the reason that it doesn't work and let us know! At the same time you'll be doing a service to the mod_perl community and helping yourself learn about mod_perl. Try to understand everything in the test configuration. Is there already a process listening on port 8529? Can you start Apache manually with the test configuration? Do you know where the logs are? Anything in them? 73, Ged.
Re: Best book
The Eagle Book, "Writing Apache Modules in Perl and C" by Lincoln Stein (CGI.pm author) and Doug MacEachern (someone who despite his mere humanity, wrote mod_perl) Published by O'Reilly ISBN 1-565592-567-X The X is for Xtra good mod_perl book. :)
Re: basic setup of mod_perl
Hi there, On Sat, 1 Jul 2000, Kristopher Lalletti wrote: I've been trying to get Apache::DBI working as soon as I mention PerlModule Apache::DBI or any other module in the httpd.conf the httpd starts-up and craps-out Read what to do in SUPPORT. 73, Ged.
mod_perl on Win32
Hello modperl, I`m trying to get ApacheModulePerl.dll to work on a Windows 98 machine. I have compiled perl apache and tring to build the module but the linker says it can not link the module because of an unresolved symbol _ap_validate_password. Has anyone succeded to run the module under win98? I will try to build it myself but it would be nice if you could send me a copy of your module. Thanks in advance. Best regards, Alexei V. Alexandrov [AA4460, AVA32-RIPN, AA1829-RIPE] *** Alexei V. Alexandrov -- www.elcomsoft.com [EMAIL PROTECTED] *** *** PGP Fingerprint:9F23 7153 51D4 FD8F 4E7F D4DF E0FA E400 ***
Re: Best book
I used the eagle book. I have done very well with it. Are there really any other books out there on the subject? Scott On 11 Jul 2000, at 10:22, Pramod Sokke wrote: Any ideas on which is the best book available out there for mod_perl?
[JOB] mod_perl developer (prefer telecommute)
I'm looking for a mod_perl developer to work directly with me on a very high profile mod_perl project. This work is on a contract basis, though very likely to lead to either full time or long term contract work. Skills involved are: Perl - good perl skills required, especially knowledge of OO. DB - Oracle preferred, also consider Sybase or PostgreSQL. mod_perl - good working knowledge of mod_perl required, though some on-the-job tuition can be provided. Protocols - some knowledge of SMTP, NNTP, IRC and MIME would be an advantage. You'll be involved in a high profile project that will be released later this year. There will probably be ongoing work involved. The work environment is fast paced, but relaxed. You'll be expected to work mostly on your own, which should be familiar territory to telecommuters. A permanent net connection is a must if you're going to telecommute on this project. Please send applications direct to me, preferably with cv/resume in PLAIN TEXT format, along with a brief summary of who you are, what you've been doing for the past 6 months, and when you can start. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Best book
On Tue, 11 Jul 2000, Scott Alexander wrote: I used the eagle book. I have done very well with it. Are there really any other books out there on the subject? Not on mod_perl, but I wouldn't develop a big system until you've read Damian Conway's "Object Oriented Perl". Scott On 11 Jul 2000, at 10:22, Pramod Sokke wrote: Any ideas on which is the best book available out there for mod_perl? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Best book
Matt Sergeant wrote: On Tue, 11 Jul 2000, Scott Alexander wrote: I used the eagle book. I have done very well with it. Are there really any other books out there on the subject? Not on mod_perl, but I wouldn't develop a big system until you've read Damian Conway's "Object Oriented Perl". Scott On 11 Jul 2000, at 10:22, Pramod Sokke wrote: Any ideas on which is the best book available out there for mod_perl? I second that! It has been an invaluable source of information. And it is very readable as well. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Why mod_perl does not like File::Recurse module?
On 11 Jul 2000, Alexei V. Barantsev wrote: From command line all is ok HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse ok/P/BODY/HTML In mod_perl I have the the different result HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse failed/P/BODY/HTML Why mod_perl does not like File::Recurse module??? Probably permissions. Under mod_perl you are running as "nobody". - Perrin
RE: Why mod_perl does not like File::Recurse module?
But nobody is typically a rather priveleged account... -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 11, 2000 2:45 PM To: Alexei V. Barantsev Cc: [EMAIL PROTECTED] Subject: Re: Why mod_perl does not like File::Recurse module? On 11 Jul 2000, Alexei V. Barantsev wrote: From command line all is ok HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse ok/P/BODY/HTML In mod_perl I have the the different result HTML LANG="en-US"HEADTITLEUntitled Document/TITLE /HEADBODYPFile::Copy::copydir ok/P PFile::Recurse::recurse failed/P/BODY/HTML Why mod_perl does not like File::Recurse module??? Probably permissions. Under mod_perl you are running as "nobody". - Perrin
Re: Best book
"Scott Alexander" [EMAIL PROTECTED] writes: I used the eagle book. I have done very well with it. Are there really any other books out there on the subject? perl.apache.org/guide of course! -- 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 -
Why can't I use a package name under Apache::Registry
Hello, I have a problem with using apache::Registry and have not been able find an answer in the eagle book or the mod_perl site, so i am missing something here. If I take the following script and run it under apache::registry it runs fine: #!/opt/perl5/bin/perl print "Content-type: text/html\n\n"; exit; If I throw a package name in there (like below) it still runs fine as a standalone script and CGI script, but under apache::registry it forwards an unrecognized header to the browser, which I cannot determine what it is. I have removed the package from the code, but still wonder why I cannot do this? #!/opt/perl5/bin/perl package myscript; print "Content-type: text/html\n\n"; exit; Thanks for any answers!
Stop the script when the user leaves
Hi all. I'm from Braz I'm writing a simple web chat and trying to do that in mod_perl. Thescript is very simple, it reads a text file with the messages and print the messages in a frame. It enters in a loop that only ends when the user send a lougout to the script. The problem that i'm havingis that if the user simply leaves the pages without clicking in logout the scripts keep running and running and don't die. How can i detect that the user leaved the script?
RE: Stop the script when the user leaves
Dimas, An automatic logoutafter a certain amount of idle time is one method. Most chat servers automatically logout and disconnect idle connections, so emulating this may not be a bad idea. There may be a way to detect that a user left the page, but if there is, I don't know about it. Thomas -Original Message-From: Dimas Kotvan [mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 12, 2000 3:16 AMTo: [EMAIL PROTECTED]Subject: Stop the script when the user leaves Hi all. I'm from Braz I'm writing a simple web chat and trying to do that in mod_perl. Thescript is very simple, it reads a text file with the messages and print the messages in a frame. It enters in a loop that only ends when the user send a lougout to the script. The problem that i'm havingis that if the user simply leaves the pages without clicking in logout the scripts keep running and running and don't die. How can i detect that the user leaved the script?
Why can't I use a package name under Apache::Registry (Continued)
Thats another weird thing. When it was happening I took that Win32::Internet() module and wrote a script to display the headers for a page I entered. It would show the headers for every page except this one! Its like it is not sending anything back. Just as a sanity check, I followed the manual way you described below and and got nothing - just disconnected. I tried the same thing to the "non-packaged" part and got the correct headers back. Nothing in the error_log either. -Original Message- From: darren [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, July 11, 2000 3:29 PM To: WBChmura Cc: darren Subject:Re: Why can't I use a package name under Apache::Registry bill chmura ([EMAIL PROTECTED]) said something to this effect: If I throw a package name in there (like below) it still runs fine as a standalone script and CGI script, but under apache::registry it forwards an unrecognized header to the browser, which I cannot determine what it is. I have removed the package from the code, but still wonder why I cannot do this? #!/opt/perl5/bin/perl package myscript; print "Content-type: text/html\n\n"; exit; Thanks for any answers! Run this on a server, connect to it via telnet, and send us the output from the browser: bash$ telnet myhost 80 GET /myscript.pl HTTP/1.0 Host: myhost ...then you can see exactly what Apache is sending. (darren) -- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car.
Re: Best book
Yes! The Eagle Book!!! Im afraid this is a "me too" email, but I am __compelled__ to write it. As a mostly self-educated programmer, I have devoured many technical books, but the Eagle book ranks as one of the best written techincal book I have ever read. Very coherent and builds up and sweeps its subject very nicely. There are many intelligent people who are masters of their subjects and have written books/tomes on their domain, but there is a big difference between understanding something well yourself and being able to explain it well to others. Lincoln and Doug, THANKS!!! The Eagle book is a major contribution to the mod_perl community and your hard work on it has not gone unnoticed. -mehryar And ofcourse Stas' ongoing contribution is without par.
RE: Why mod_perl does not like File::Recurse module?
On Tue, 11 Jul 2000, Jerrad Pierce wrote: But nobody is typically a rather priveleged account... Permissions are permissions. If you want the nobody user to read the files and directories, they have to be accessible by that user. Why mod_perl does not like File::Recurse module??? Probably permissions. Under mod_perl you are running as "nobody". - Perrin
Re: Interfacing from Apache to Access
On Tue, 11 Jul 2000, Mike Miller wrote: Not good for heavy use, but for the 3-4 times a month it gets used in production, it works perfectly okay. There is one significant issue with using DBD::Proxy / DBI::ProxyServer on Windows: lack of fork. If you're going to be using it you probably want to either use 5.6 (problem mostly solved) or start several proxies on differenct ports. Check the PlRPC Net::Daemon docs for informations about forking. This is mainly annoying because only one connection can use the single process proxy at once. Otherwise we've seen no problems with using it as production method to slurp data from an Access DB into a RRDBMS (Real Relational Database Management System tm). Jonathan Conway Senior DBA ipoPros.com
Re: mod_perl on Win32
On Tue, 11 Jul 2000, Alexei V. Alexandrov wrote: Hello modperl, I`m trying to get ApacheModulePerl.dll to work on a Windows 98 machine. I have compiled perl apache and tring to build the module but the linker says it can not link the module because of an unresolved symbol _ap_validate_password. Has anyone succeded to run the module under win98? I will try to build it myself but it would be nice if you could send me a copy of your module. Hi, Did you link against ApacheCore.lib? In the mod_perl dsp file, you may need to adjust the path to where ApacheCore.lib is on your system (and also the path to Perl's perl.lib [renamed to perl56.lib for Perl-5.6.0]). Also, make sure ApacheCore.lib is from the same apache distribution as is being used for the apache inc/ directory in building ApacheModulePerl.dll. best regards, randy kobes
Re: Interfacing from Apache to Access
On Tue, 11 Jul 2000 15:10:25 -0600 (MDT), rise wrote: On Tue, 11 Jul 2000, Mike Miller wrote: Not good for heavy use, but for the 3-4 times a month it gets used in production, it works perfectly okay. There is one significant issue with using DBD::Proxy / DBI::ProxyServer on Windows: lack of fork. If you're going to be using it you probably want to either use 5.6 (problem mostly solved) or start several proxies on differenct ports. Check the PlRPC Net::Daemon docs for informations about forking. This is mainly annoying because only one connection can use the single process proxy at once. Otherwise we've seen no problems with using it as production method to slurp data from an Access DB into a RRDBMS (Real Relational Database Management System tm). Thanks for the info. I've never hit this because the only process that uses the proxy is initiate from a cron job (on a unix box) that runs every hour looking for updates in the access db (which gets updated 3-4 times a month, if that grin). It is also the only task that ever uses the proxy, so of course I'd never see it. For me the entire entire thing was a hack, but what the hey, it works ... grin Brgds, Mike.
Apache::session and Apache::DBI::Oracle headaches
Having a bit of trouble getting apache::session to run with apache::DBI. Is this due to the fact that Oracle wants AutoCommit on and Apache::DBI has it off or is there some other magic that I am missing out on? Is anyone using Apache::Session with Apache::DBI??? The error_log reports finding an existing DBI connection but no data is written to the tables. Autocommit is off...I remember reading something about Session::store() but can't find it anywhere. Can anyone help. On a Solaris Apache 1.3.12 Perl 5.6.0 mod_perl 1.24 most recent Apache::Session most recent DBI.pm Oracle 8i Chad Alan Billigmeier Software Engineer 160 Second Street Cambridge, MA 02142-
[ ANNOUNCE ] Apache::PerlVINC v0.02
All, ok. after much twiddling and tweaking, I have finished a version of Apache::PerlVINC that I feel comfortable with. I changed _alot_ of things in it. maybe too much. i thought it would be nice if _everybody_ had a chance to flame me, so I am including a link so you can download it and try it. http://dave.devel.epals.com/misc/Apache-PerlVINC-0.02.tar.gz Apache::PerlVINC is a module that allows multiple versions of a script or module to run on the same server. It works by reloading the specified files at request. Because of this, it is meant for use only in a development environment. I totally revamped the directives. I removed the PerlVersionINC On/Off directive. I didn't see the need for it once DIR_CREATE is involved. Secondly, I traded the use of PerlRequire with PerlVersion. the reasoning behind this was so that if the file wasn't there, the server would still start. Also, this way you dont have to worry about setting PERL5LIB or "use lib 'xxx'". I thought it might make things easier and more intuitive. if I am wrong, Im sure i'll hear about it. I think my biggest concern is for all the people using it already; it doesn't work like it used to. They will have to change their config directives to upgrade. Is that really a big deal? Also, the docs that Stas Bekman wrote will be outdated by this release. I can spruce those up if necessary. If I receive no response, I will assume either everyone likes it or nobody cares, and I will publish it to CPAN. dave -- Dave Moore Web Application Developer mailto:[EMAIL PROTECTED] ePALS Classroom Exchange http://www.epals.com/ The world's largest online classroom community - Connecting over 27,000 classrooms in 130 countries!
Yet more on set_handlers() and new-found problems with lookup_uri()
Hello, again. We're making progress; I think I've decided what the actual bugs are. :) Please let me know if you disagree. On certain requests, such as requests which ask for directories and require the aid of DirectoryIndex, lookup_uri() is called. This call creates a subrequest that appears as if it is a new one up until the content handler phase. From the eagle book, pages 452-3: lookup_file() and lookup_uri() invoke Apache subrequests. A subrequest is treated exactly like an ordinary request, except that the post read request ... [is] not run... lookup_uri() performs the URI translation on the provided URI, passing the request to the access control and authorization handlers, if any... The bugs, I believe are the following two: 1) set_handlers() doesn't do what it claims except with respect to using undef. If you add handlers in, it is ignored, at least if the handlers you are trying to add are in the same phase the handler from which you are calling set_handlers(). This bug is evident in the error log snippet attached. It shows that, even though I call set_handlers twice in a row, once to clear the stack and once to add the AuthzCache::dummy handler, the dummy method in fact is not added as shown in the subrequest. I've also attached the AuthzCache code with the debug statements included. 2) The subrequest's handlers stack is not reset to what it was when the initial request began. It is whatever is left from the initial request's processing up to the point that the subrequest launched. Here's the important steps that occur when I request a directory URL (ie, /foo/). 1) AuthzCache runs and has a hit. It clears the all handlers in the phase and returns OK. 2) lookup_uri() is called and the first name in DirectoryIndex is examined. 3) While running through the phases for this subrequest, the PerlAuthzHandlers is empty. 4) The subrequest completes with what I presume is an AUTH_REQUIRED error, since the user didn't match the required group. 5) Steps 2 through 4 are called for all DirectoryIndex files. The server finally returns the directory contents instead. The second bug may not be a bug, per se, but while it functions like it does, I don't see any way to do what I want while the first bug with set_handlers exists. If I could set_handlers(PerlAuthzHandlers = [ \OK ]) and the handler stack would actually be modified, I'd be set. I'll keep banging away on this problem, but I'd appreciate hearing from y'all whether you can reproduce my problems and whether you believe I'm right with respect to the analysis of the problems. Regards, Christian -Original Message- From: Christian Gilmore [mailto:[EMAIL PROTECTED]] Sent: Friday, July 07, 2000 3:34 PM To: Modperl Mailing List (E-mail) Subject: More on the set_handlers() / push_handlers() bug... Hello, again. Here's a quick summary of the problem: upon clearing the stack of handlers (with set_handlers(PerlAuthzHandlers = undef)) the server appears to not recognize when it has found a DirectoryIndex file and returns the contents of a directory instead of the index file. Since last writing on this topic, I upgraded to all of the newest versions (apache-1.3.12, perl-5.6, mod_perl-1.24) and configured mod_perl with PERL_TRACE=1. Looking at the error_log with the handler tracing on and httpd running in single-server mode, I discovered that the server does appear to cycle through the directory indexes, but doesn't realize when it has found one. I've attached two error logs for the request http://dw3.tivoli.com:81/home/passwd/group/: one with the cache enabled, one without. I've also attached a copy of the document returned by the server for the with-authz-cache request. The document is the auto-generated contents of the directory. As you can see, index.phtml does exist in the directory and is the first file searched for by the server. Does anyone have any ideas here? Can anyone reproduce the problem? I've also included the source for the AuthzCache and AuthzLDAP. If anyone could use at least the Cache code and see if you could reproduce the problem, I'd really appreciate it. I noticed that the error log with the cache enabled shows that subsequent internal requests (such as those you see when requesting a directory instead of a named file) don't reset the handler stack to what is in the configuration. See about line 65 of each log file for this difference. Regards, Christian - Christian Gilmore Infrastructure Tools Team Lead Web Multimedia Development Tivoli Systems, Inc. - AuthzCache.pm - AuthzLDAP.pm - group-dir.html - error_log_with_cache - error_log_without_cache AuthzCache.pm error_log_with_cache
Newbie: make test failure FIXED!
From: G.W. Haywood [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 12 July 2000 3:45 AM To: mod_perl Mailing List Subject: Re: Newbie: make test failure! Hi there, On Fri, 7 Jul 2000, Michael Robinton wrote: On Sat, 8 Jul 2000, Greg Leidreiter wrote: but when I run 'make test' httpd listening on port 8529 letting apache warm up...\c still waiting for server to warm up.not ok I always get that error. I always ignore the error and everything seems to work fine. Running `make test' successfully is IMPORTANT! Please try to find the reason that it doesn't work and let us know! At the same time you'll be doing a service to the mod_perl community and helping yourself learn about mod_perl. Try to understand everything in the test configuration. Is there already a process listening on port 8529? Can you start Apache manually with the test configuration? Do you know where the logs are? Anything in them? 73, Ged. - That seems like a fair call Ged. I have messed around with the config of this so much now that it's difficult to isolate the specific cause. However, here is a potted history in case it's of use to anyone. So make test failed, and as Michael suggested I ignored it and sure enough Apache seemed to start and run OK (mod_perl.c came up under httpd -l) - did all the things that a good web server should , EXCEPT that it returned 403 for every URL I entered into the browser. I rebuilt Apache as a standalone server (ie: using vanilla defaults / without Mod_perl) and suffered exactly the same problems (make test failure, constant 403 returns), which seemed to let mod_perl off the hook as a culprit at least. Moreover the latter problem suggested a fairly simple config error on my part - but it took me a while to track it down :-) Eventually, I noticed that the ServerRoot permissions were set to drwx-- which prevents user "nobody" from accessing this directory. Never crossed my mind before that this was an issue - I simply thought that "nobody" was interested in the DocumentRoot tree (and associated Symlinks). So reset permissions on ServerRoot and hey presto! no more 403 errors! Next I recompiled Apache from/with mod_perl and make test no longer fails! So I assume these issues are related... Cheers, Greg.
RE: The Eagle has landed!
-Original Message-
From: Darko Krizic [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 11 July 2000 10:56 PM
To: 'Greg Leidreiter'
Subject: RE: The Eagle has landed!
ServerRoot is /usr/local/apache
underneath which I have created the lib/perl/Apache tree for holding
mod_perl modules,
and dutifully entered the required code in a file called
Hello.pm in this
directory.
DocumentRoot is /usr/local/apache/htdocs
in httpd.conf I have added the following:
--
IfModule mod_perl.c
Include conf/perl.conf
/IfModule
--
conf/perl.conf looks like this:
--
PerlRequire conf/startup.pl
PerlFreshRestart On
Location /hello/world
SetHandler perl-script
PerlHandler Apache::Hello
/Location
---
and startup.pl looks like this:
---
#!/usr/local/bin/perl
print "\n\tstartup.pl is attempting to modify the include
path...\n\n";
BEGIN {
use Apache();
use lib Apache-server_root_relative('lib/perl');
}
use Apache::Registry
use Apache::Constants
use CGI qw(-compile :all);
use CGI::Carp;
1;
--
You must add the directory /usr/local/apache/lib/perl to you @INC, for
example like that in your httpd.conf
Perl
push @INC,"/usr/local/apache/lib/perl";
/Perl
If you reference an Module named Apache::MyMod then it is searched as
/usr/local/apache/lib/perl/Apache/MyMod.pm.
...darko
Hmm, while I do appreciate the logic of this approach I remain sceptical for
a number of reasons.
Firstly becuase the Eagle book seems very rigorous to me, and such an
oversight as forgetting to push a path into @INC should have been picked up
well before now. I've never heard mention of this problem... Moreover, Stein
and MacEachern *do* address the issue of having to add another lib path. In
my understanding that's exactly the point of the BEGIN block in startup.pl -
it's just that for some reason this doesn't seem to be getting picked up
properly.
Secondly, when I added the Perl push ... directive to perl.conf the server
repeatedly failed to start (which may provide a clue to those of you out
there who know a lot more than I do) even though it came up with Syntax OK
under httpd -t.
Any other suggestions?
Cheers,
Greg.
Re: Apache::session and Apache::DBI::Oracle headaches
On Tue, 11 Jul 2000, Chad Billigmeier wrote: Having a bit of trouble getting apache::session to run with apache::DBI. Is this due to the fact that Oracle wants AutoCommit on and Apache::DBI has it off or is there some other magic that I am missing out on? Is anyone using Apache::Session with Apache::DBI??? The error_log reports finding an existing DBI connection but no data is written to the tables. Autocommit is off...I remember reading something about Session::store() but can't find it anywhere. Can anyone help. I quote from the Apache::Session::Oracle perldoc: The special Apache::Session argument for this module is Commit. You MUST provide the Commit argument, which instructs this module to either commit the transaction when it is finished, or to simply do nothing. This feature is provided so that this module will not have adverse interactions with your local transaction policy, nor your local database handle caching policy. The argument is mandatory in order to make you think about this problem. If that isn't enough information, let us know. Your problem report is incomplete and confusing, so we will need a more clear picture before we can provide more help. Best Regards, Jeffrey Baker
Re: [ ANNOUNCE ] Apache::PerlVINC v0.02
On Tue, 11 Jul 2000, Dave Moore wrote: All, ok. after much twiddling and tweaking, I have finished a version of Apache::PerlVINC that I feel comfortable with. I changed _alot_ of things in it. maybe too much. i thought it would be nice if _everybody_ had a chance to flame me, so I am including a link so you can download it and try it. http://dave.devel.epals.com/misc/Apache-PerlVINC-0.02.tar.gz Apache::PerlVINC is a module that allows multiple versions of a script or module to run on the same server. It works by reloading the specified files at request. Because of this, it is meant for use only in a development environment. I totally revamped the directives. I removed the PerlVersionINC On/Off directive. I didn't see the need for it once DIR_CREATE is involved. Secondly, I traded the use of PerlRequire with PerlVersion. the reasoning behind this was so that if the file wasn't there, the server would still start. Also, this way you dont have to worry about setting PERL5LIB or "use lib 'xxx'". I thought it might make things easier and more intuitive. if I am wrong, Im sure i'll hear about it. I think my biggest concern is for all the people using it already; it doesn't work like it used to. They will have to change their config directives to upgrade. Is that really a big deal? Also, the docs that Stas Bekman wrote will be outdated by this release. I can spruce those up if necessary. I'll gladly update those if you send me the updated info. Thanks! If I receive no response, I will assume either everyone likes it or nobody cares, and I will publish it to CPAN. dave -- Dave Moore Web Application Developer mailto:[EMAIL PROTECTED] ePALS Classroom Exchange http://www.epals.com/ The world's largest online classroom community - Connecting over 27,000 classrooms in 130 countries! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
