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
On Thu, 17 Aug 2000, Dave Jenkins wrote:
I'd appreciate some help with a nasty little intermittent problem.
I'm running...
Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.9 OpenSSL/0.9.4
on a SuSE 6.2 box (2.2.10 kernel)
Mostly everything is fine, but now and then the following error
On Thu, 17 Aug 2000 [EMAIL PROTECTED] wrote:
Let me start with "I'm new".
If this is the wrong forum, let me know now and please direct me to the right
place.
I come from the Mac/Windows world.
I'd like to know howm to check on the status of Apache via perl and what
commands are
On Tue, 15 Aug 2000, vegan.star wrote:
I have some mod_perl modules. I suspect that it has a memory
leak. I'm running that in a Sun Solaris 2.6 machine with apache
1.3.9. I read that exists Apache::Leak to test for leaks.
How it works?
I have some packages and I put into them like
On Tue, 15 Aug 2000, Edward Moon wrote:
Yes, I have read that part of the mod_perl guide. I'm looking for a more
detailed discussion on mod_proxy configuration and performance.
But it doesn't answer the questions I have regarding the use of mod_proxy:
* What affect does CacheGcInterval
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
-
Hi Pritesh,
However, the same code is not working under mod_perl. The file
content is the same as original file, but filename is populated as
download.cgi instead of actual file name. I think mod_perl is
putting its own headers, while sending the data.
Are you using the PerlSendHeader On
Has anyone converted the Ultimate Bulletin Board / Madron Park Bulletin
board to run under mod_perl ?
Hi,
We have a site where we create a session file on
login and tie some values.
After a few page visits we want to add more values
to the session file again using tie.
We find that only the first set of values get
added. Subsequent values do not get added to this file.
Can somebody tell us
Not
with so little information...
Afew ideas though:
I assume you are speaking of
Apache::Session?
Are you adding values lower than the
top level? The man page clearly states no deep checking is done to determine if
modifications have been made...
Have you tried explicitly
untie'ing?
To close loop , I discovered I had redundant Location directives for
/hello/world amongst my various *.conf files. Once I got rid of the
extras I was good to go. Thanks for ideas !
Tony
Tony Whyte wrote:
Running apache-1.3.11, mod_perl-1.24, irix6.5.5
this works: (gets handled by mod_perl)
Hello ,
Your problem is an classic example of an incorrect
implementation of tie function
In fact the session acts like this :
1)You tie your hash (INDIRECTLY linket to the
database)
2)You put your data in the hash but it still in memory because
it is quite stupid and slow to put
it
"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
"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
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
Your e-mail has been received by the Perl Bug Squashing Team.
A Bug ID (2818.003) has been assigned and is shown in the subject of this email.
Please include this bug ID in the subject line of any followup messages.
This is an automatic confirmation message.
--
Perl Bug Squashing Team
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.28 running under perl v5.6.0.
-
Building mod_perl fails the following tests:
modules/symbol..ok 1/2FAILED test 2
I the past 6 weeks I have been working on various problems with
Apache/mod_perl/AutoIndex.pm.
There needs to be a "Your Mileage May Vary" (YMMV) reference page that is
easily accessible.
For Example,after scratching at the mouse pad, I found the following URLs
with practical information:
Ok. I finally got mod_perl doing what I want it to do.
Except for one problem. after anywhere from 10 minutes, to half an hour, on a
server with 768megs of ram, it starts eating swap.
How can I keep the processes small and not growing to ungodly sizes (13 megs
per process, unsure of how much
"Mike Hodson" [EMAIL PROTECTED] writes:
I've looked at different documentation, but the methods they give only slow
the use of swap, and the processes keep growing, yet slower..
And that documentation included:
http://perl.apache.org/guide ?
From start to finish?
--
Dave Hodgkinson,
i canna get the PerlAuthenHandler to do ANYTHING. first
line of code after $r = shift is $r-warn() but nothing
shows up in the log. aaugh!
i copied the sample code from 'illustrated security scenarios'
at http://perl.apache.org/guide/security.html nearly verbatim,
(cut paste + munge) changed
i canna get the PerlAuthenHandler to do ANYTHING. first
line of code after $r = shift is $r-warn() but nothing
shows up in the log. aaugh!
i copied the sample code from 'illustrated security scenarios'
at http://perl.apache.org/guide/security.html nearly verbatim,
(cut paste + munge)
!) 'Do not' load mod_perl as a DSO.
2) 'Do not': "PerlFreshRestart On" in httpd.conf.
Curiously enough, "PerlFreshRestart On" has always worked for me, even
on the production servers.
It's pretty damn useful too, giving servers a graceful restart everytime
you upload a module... it'd be a
i canna get the PerlAuthenHandler to do ANYTHING. first
line of code after $r = shift is $r-warn() but nothing
shows up in the log. aaugh!
[snip]
Location /auth
PerlAccessHandler Serensoft::Auth::access_handler
PerlSetVar Intranet "this = that"
Hi guys,
My company, Tradiant, is looking for a Web Developer to work on our
new Information Services portal. Below is the job posting and if you're
still interested, read my take on the company:
-
Web Developer
The candidate will work closely in developing Tradiant's Informational
On Fri, 18 Aug 2000, Roger Espel Llima wrote:
!) 'Do not' load mod_perl as a DSO.
This should be a golden rule if you plan on HUPing your server with any
regularity.
2) 'Do not': "PerlFreshRestart On" in httpd.conf.
Curiously enough, "PerlFreshRestart On" has always worked for me, even
thanks for your posts, guys!
Eric Cholet replied:
i copied the sample code from 'illustrated security scenarios'
at http://perl.apache.org/guide/security.html nearly verbatim,
(cut paste + munge) changed '(*PASSED*)' to a simple test
(moot, at this point) and inserted a few $r-warn("")
I get the behaviour described in the BUGS section of the docs: server
silently fails to start.
However, I'm using the latest version of Apache::ExtUtils, as
recommended.
Also using mod_perl 1.22, Apache 1.3.12, Apache::ASP 2.03.
Has anyone got PerlVINC to work with this combo?
Tom
On Fri, 18 Aug 2000, George Sanderson wrote:
I the past 6 weeks I have been working on various problems with
Apache/mod_perl/AutoIndex.pm.
There needs to be a "Your Mileage May Vary" (YMMV) reference page that is
easily accessible.
For Example,after scratching at the mouse pad, I found
On Fri, 18 Aug 2000, will trillich wrote:
thanks for your posts, guys!
Eric Cholet replied:
i copied the sample code from 'illustrated security scenarios'
at http://perl.apache.org/guide/security.html nearly verbatim,
(cut paste + munge) changed '(*PASSED*)' to a simple test
On Fri, 18 Aug 2000, Tom Lancaster wrote:
I get the behaviour described in the BUGS section of the docs: server
silently fails to start.
However, I'm using the latest version of Apache::ExtUtils, as
recommended.
Also using mod_perl 1.22, Apache 1.3.12, Apache::ASP 2.03.
Has anyone got
That's the version I'm using, and it's in the docs for that module that
the problem I'm having is described. It claims to be fixable by using
the latest ExtUtils. I guess not :(
I suppose I'd better update my mod_perl.
Stas Bekman wrote:
On Fri, 18 Aug 2000, Tom Lancaster wrote:
I get
On Fri, 18 Aug 2000, Tom Lancaster wrote:
That's the version I'm using, and it's in the docs for that module that
the problem I'm having is described. It claims to be fixable by using
the latest ExtUtils. I guess not :(
Oh, Ok. I thought I've been using an older version of it.
I suppose
Ok. I finally got mod_perl doing what I want it to do.
Except for one problem. after anywhere from 10 minutes, to half an hour,
on a
server with 768megs of ram, it starts eating swap.
How can I keep the processes small and not growing to ungodly sizes (13
megs
per process, unsure of how
Hello:
Is there any more documentation besides the perldoc on
how to use Apache::Cookie (it's not enough for me :(,
I need something a bit more tutorially oriented, and
the Eagle Book doesn't cover it)?
Thanks in advance.
Christopher Everett
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
On Fri, 18 Aug 2000, Christopher Louis Everett wrote:
Hello:
Is there any more documentation besides the perldoc on
how to use Apache::Cookie (it's not enough for me :(,
I need something a bit more tutorially oriented, and
the Eagle Book doesn't cover it)?
Thanks in advance.
On Fri, 18 Aug 2000, Roger Espel Llima wrote:
!) 'Do not' load mod_perl as a DSO.
This should be a golden rule if you plan on HUPing your server with any
regularity.
2) 'Do not': "PerlFreshRestart On" in httpd.conf.
Curiously enough, "PerlFreshRestart On" has always worked for me, even
Stas Bekman wrote:
snip
I'm not sure how much this will be of a tutorial but try:
http://thingy.kcilink.com/modperlguide/porting/Starting_with_mod_cgi_Compatible.html
This is to say then, that one uses Apache::Cookie, just like one would
use CGI::Cookie?
Everett
PS. Thanks for the
On Fri, 18 Aug 2000, Christopher Louis Everett wrote:
Stas Bekman wrote:
snip
I'm not sure how much this will be of a tutorial but try:
http://thingy.kcilink.com/modperlguide/porting/Starting_with_mod_cgi_Compatible.html
This is to say then, that one uses Apache::Cookie, just
richter 00/08/18 02:21:05
Modified:embperl Changes.pod.1.html
Log:
Embperl Webpages - Changes
Revision ChangesPath
1.165 +3 -1 modperl-site/embperl/Changes.pod.1.html
Index: Changes.pod.1.html
41 matches
Mail list logo
