Re: Problems compiling libapreq C libs on solaris 7....
> >*) Solaris 7 > >*) libtool 1.4.2 > >*) automake 1.4-p5 > >*) autoconf 2.50 > > > >./configure works, but when I type make, I get the following error: > > perl Makefile.PL and make, per the INSTALL file work for me. I'm interested in the C routines, not the perl routines (have them working and know how to get them to work ::grin::). I can do a perl Makefile.pl && make and the build works fine, but like I said, I'm interested in the C routines as well as the perl ones or are the C routines largely a myth? Thanks. -sc PS Is there a prefix directive for the Makefile.PL that'll let me change the installation directory (don't want to toss this into the main perl tree). -- Sean Chittenden
Problems compiling libapreq C libs on solaris 7....
Howdy. Let me cut to the chase: *) Solaris 7 *) libtool 1.4.2 *) automake 1.4-p5 *) autoconf 2.50 ./configure works, but when I type make, I get the following error: ../libapreq-0.33> make cd . && aclocal aclocal: configure.in: 8: macro `AM_PROG_LIBTOOL` not found in library make: *** [aclocal.m4] Error 1 ../libapreq-0.33> And I'm stumped. I can create the perl libs w/o a hitch, but when I try to create just the C libs I get this error. Any magic wand waving that I need to do, or is this a case of needing to whack the Solaris team with the clue bat for some Sun idiosyncrasy? -sc -- Sean Chittenden
Re: Problems installing libapreq
> NT> And especially why the weird error: > > NT> root@wm-server /tmp/libapreq-0.33>make > NT> Making all in c > NT> "Makefile", line 278: Need an operator > > Are you on a BSD system? The make is probably incompatible. GNU make > (the default on Linux) uses different syntax for some things. If > you're not using GNU make to build perl-related things, you > should. ;-) Why not use the ports to install this (if FreeBSD)? If that's not an option, then use gmake as suggested. -sc -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
> What would really help is if all the ISPs out there put filters on their > routers to catch these requests as close to their source as possible. Hey. Real quick, this discussion is getting a tad off topic, but, in terms of security, the ideal way to handle this is and prevent future spread of such worms for all of the IIS users in the crowd: * setup a bank of webservers * setup your scripts to use a proxy server * put a firewall before your webservers and proxy servers * deny all traffic FROM your webservers to port 80 and 443 * allow all traffic from your proxy server Cheers. Now can we get back to mod_perl? -sc -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
> > > Anybody know of any module I can use to hit back at these default.ida bozos > > > (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on > > > Win32. > > > [snip] > > ::grin:: In the post he mentioned about trashing the kernel on NT so > > this might be kinda fun... > > Well you might think it's fun but there are those who'd say it's criminal. Sorry, you're right. I meant fun in the same way that Looney Toons and Wilie Coyote. Funny to watch a cartoon fall off a cliff, but not necessarily funny in life. > Please don't promote irresponsible ideas on the mod_perl List. My bad script kiddies, go away, grow up, be responsible, and look to other security oriented lists such as incidents and bugtraq for bad ideas. -sc PS Bad ideas aren't bad, execution of bad ideas is bad. -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
> Anybody know of any module I can use to hit back at these default.ida bozos > (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on > Win32. I remember a post on incidents or bugtraq where someone started pumping crap data back at the virus and eventually the NT system crashed. I haven't tried this, but it might be worth a shot to look in the archives and see if you can replicate this persons's results. ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... at the same time, because no one else has done something like this suggests that it may not work. YMMV. -sc -- Sean Chittenden PGP signature
Re: UNSUBSCRIBE?????????????
Read the mail headers... -sc On Thu, Jul 26, 2001 at 04:22:21PM -0700, OTR Comm wrote: > Return-Path: <[EMAIL PROTECTED]> > Delivered-To: [EMAIL PROTECTED] > Received: (qmail 84735 invoked from network); 26 Jul 2001 23:22:44 - > Received: from h31.sny.collab.net (HELO apache.org) (64.208.42.41) > by perrin.tgd.net with SMTP; 26 Jul 2001 23:22:44 - > Received: (qmail 44418 invoked by uid 500); 26 Jul 2001 23:22:17 - > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Precedence: bulk > list-help: <mailto:[EMAIL PROTECTED]> > list-unsubscribe: <mailto:[EMAIL PROTECTED]> > list-post: <mailto:[EMAIL PROTECTED]> > Delivered-To: mailing list [EMAIL PROTECTED] > Received: (qmail 44386 invoked from network); 26 Jul 2001 23:22:16 - > Message-ID: <[EMAIL PROTECTED]> > Date: Thu, 26 Jul 2001 16:22:21 -0700 > From: OTR Comm <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.06 [en] (WinNT; U) > MIME-Version: 1.0 > To: [EMAIL PROTECTED] > Subject: UNSUBSCRIBE? > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > I have tried and tried and tried to get unsubscribed from this list and > it does not seem to happen. > > Anybody have any clues about how to do this? > -- Sean Chittenden PGP signature
Re: BSDI 4.1 make issues...
This took a while to track, but this may be useful in the archives: I was using an old version of apxs that came with Apache 1.3.12, not 1.3.20. Change your path to include the newwer apxs and everything's groovy. -sc > Should I be worried? I've never seen this before... I want > build mod_perl as a DSO. THoughts? -sc > > # perl Makefile.PL USE_APXS=1 EVERYTHING=1 PREFIX=/usr/local >WITH_APXS=/usr/local/sbin/apxs >PERL_EXTRA_CFLAGS='-DDEFAULT_PATH=\"/bin:/usr/bin:/usr/local/bin\"' > Will configure via APXS (apxs=/usr/contrib/bin/apxs) ^ [snip] > require: not found > use: not found > package: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected > require: not found > use: not found > package: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected > require: not found > use: not found > package: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > my: not found > /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected > Configuring mod_perl for building via APXS > + Creating a local mod_perl source tree > + Setting up mod_perl build environment (Makefile) > + id: mod_perl/1.26 > + id: Perl/5.00503 (bsdos) [perl] > Now please type 'make' to build libperl.so > Checking CGI.pm VERSION..ok > Checking for LWP::UserAgent..ok > Checking for HTML::HeadParserok > Checking if your kit is complete... > Looks good > Writing Makefile for Apache > Writing Makefile for Apache::Connection > Writing Makefile for Apache::Constants > Writing Makefile for Apache::File > Writing Makefile for Apache::Leak > Writing Makefile for Apache::Log > Writing Makefile for Apache::ModuleConfig > Writing Makefile for Apache::PerlRunXS > Writing Makefile for Apache::Server > Writing Makefile for Apache::Symbol > Writing Makefile for Apache::Table > Writing Makefile for Apache::URI > Writing Makefile for Apache::Util > Writing Makefile for mod_perl -- Sean Chittenden PGP signature
BSDI 4.1 make issues...
Should I be worried? I've never seen this before... I want build mod_perl as a DSO. THoughts? -sc # perl Makefile.PL USE_APXS=1 EVERYTHING=1 PREFIX=/usr/local WITH_APXS=/usr/local/sbin/apxs PERL_EXTRA_CFLAGS='-DDEFAULT_PATH=\"/bin:/usr/bin:/usr/local/bin\"' Will configure via APXS (apxs=/usr/contrib/bin/apxs) PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'wheel' require: not found use: not found package: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected require: not found use: not found package: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected require: not found use: not found package: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found my: not found /usr/contrib/bin/apxs: 87: Syntax error: ";" unexpected Configuring mod_perl for building via APXS + Creating a local mod_perl source tree + Setting up mod_perl build environment (Makefile) + id: mod_perl/1.26 + id: Perl/5.00503 (bsdos) [perl] Now please type 'make' to build libperl.so Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Checking if your kit is complete... Looks good Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl -- Sean Chittenden PGP signature
Re: Post processing Perl output through PHP
> There must be an easier way !!! Sorry. <:~) You could hack mod_proxy or mod_backhand and put PHP on a different server (or same server on different port). If you have to pick between the two, I recommend backhand (comes with a lot of other really nice features). http://www.backhand.org/ -sc > Please help me... I've spent over 20 hours reading nearly every forum > on phpbuilder.net and a whole host of other sites now, and I've found > two others who have exactly the same problem as me, and having emailed them, > they never found an elegant solution... they ended up re-writing all their > code in one or the other. Yup, sorry. Apache 2.0 has filter support so this may be an easier solution in the future. I'm writing ruby-tmpl (mod_ruby module) that has output processing because this isn't an easy problem to solve. > But I've got over 40,000 lines of Perl, and the entire rest of the site is > in PHP, so this is an unbelievable task if I have to resort to it !?!?!? Bummer if this is for a company, you may want to look into an outside contracting firm to help you with this. ;~) http://www.mha.ca/ - These guys are great PHP contractors that I've used before. -sc -- Sean Chittenden PGP signature
Solaris mod_perl DSO...
Has anyone had any luck getting mod_perl to work as a DSO on Solaris? In looking through the sources, it looks like my only option is to upgrade to bleed perl. If that really is the only thing I can do, can someone quickly second my thoughts before I go and subject myself to a little piece of something other than heaven? Thanks. -sc -- Sean Chittenden PGP signature
Re: Sendmail or not?
> No, Mail::Sendmail sends through SMTP. That's why I talked about it. My bad, next time I'll check out the readme. > So, you're saying that I should just fork anyway? If you have an SMTP server that's available for relaying from your host, I'd go for Mail::Sendmail because it seems like a simple interface. > Will there be a big performance loss on Linux? Naw, Linux and FreeBSD are extremely quick at forking. > And should I use Apache::Subprocess for this, or just go ahead with > a standard pipe? Standard pipe is probably okay for your site. Unless you've got a load of .40 or higher, I wouldn't worry about this (and .4 is probably even little low to be worrying about this). Motto: Get it done. If there's a problem, fix it later. Don't prevent yourself from fixing a problem if one arrises. -sc -- Sean Chittenden PGP signature
Re: Sendmail or not?
if you | to sendmail, then you still fork. Mail::Sendmail, I bet dime to dollar, forks and execs a process. The only way to avoid forking is to open a socket and send the message via SMTP (or QMQP if you want to pimp your system out with qmail). Unless you're on AIX or solaris and performance is an issue, fork and get the job done w/ minimal headaches. -sc On Sun, Apr 08, 2001 at 08:52:38AM +0200, Per Einar wrote: > There is still one subject about subprocesses under mod_perl which is > unclear to me: should I avoid pipes ot other programs or not? > > What I have understood is that I should avoid forking subprocesses. > > Now, here is my case: I want to send an e-mail to somebody. Should I open a > pipe to sendmail (with open my $fh = gensym(), '|sendmail -t -oi'), or > should I avoid this and use a Perl module like Mail::Sendmail. > > While I think Mail::Sendmail could provide what I need, I guess that > sendmail is better at handling message queues etc, so it will be preferable > to use that. > > What is the best choice in my case? > > Per Einar Ellefsen > [EMAIL PROTECTED] > > > -- Sean Chittenden PGP signature
Lustful thought re: Apache 2.0... (was Re: Apache::Compress and Apache::Filter)
I can't wait till stacked filters take care of this... Apache 2.0/mod_perl 2.0 is going to really sweet maybe this weekend I'll setup apache 2.0 as a proxy server back to my 1.3 boxes so I can use filters hmmm. >:~) -sc PS For those of you who weren't here, the mod_perl 2.0/Apache/2.0 talks by Doug/Ryan (respectively) were really awesome!!! The demo from Doug was pretty damn swift... imagine being able to do s/before/after/g on a piece of outgoing data... sessions have never been more cool/easy. On Thu, Apr 05, 2001 at 05:02:41PM -0400, JR Mayberry wrote: > Does anyone know anything about the above combo, and getting an error > message: > Bad filehandle at Filter.pm line 123 > > when using a client that doesnt support gzip..(specifically 'ab', apache > bench) > > I may be something wrong but its only breaking when a client doesnt support > gzip > > thanks > > -- Sean Chittenden PGP signature
Re: [OT?] %ENV question, mod_rewrite vs. mod_perl?
Use a mod_perl transhandler for this, it's the phase of the
apache process that's responsible for matching the URI/request to a
file that'll be executed in the response phase.
http://perl.apache.org/guide/snippets.html#PerlTransHandler_example
-sc
On Mon, Mar 19, 2001 at 07:42:14PM -0800, Paul Evad wrote:
> Delivered-To: [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> X-Sender: [EMAIL PROTECTED]
> Date: Mon, 19 Mar 2001 19:42:14 -0800
> To: [EMAIL PROTECTED]
> From: Paul Evad <[EMAIL PROTECTED]>
> Subject: [OT?] %ENV question, mod_rewrite vs. mod_perl?
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
> I'm new to mod_perl, so please bear with me a bit. I'm digging
> through as much information as I can find and have a few questions.
>
> I've used mod_rewrite for a lot of URI re-mapping solutions, but this
> particular job I'm doing is a bit of a challenge.
>
> I have an existing perl script (non mod_perl) which checks against a
> number of ENV variables to determine which 'file' the browser should
> see.
>
> Trouble is, that script reads the file and spits it out to the
> browser, which makes it useless for anything with SSI or PHP based
> solutions.
>
> My logic had me thinking that I could use mod_rewrite to query the
> script, and rewrite the URI slightly according to what that script
> spit back. Then apache could fill the request and SSI and PHP stuff
> would remain intact (and be parsed).
>
> So I wind up with
>
> RewriteEngine on
> RewriteLogLevel 9
> RewriteLog /home/httpd/logs/rewrite.log
> RewriteMapfoo prg:/home/httpd/cgi-bin/foo.cgi
> RewriteRule ^/(.+\.(html|htm|php|php3))$ /${foo:$1} [L]
>
> which basically says, pass the URI to foo and give back a rewritten
> URI, then go fetch it.
>
> trouble is, due to the way the Map works, the foo.cgi is launched
> then 'stays' launched, and from what I can tell has no access to the
> %ENV variables that it would normally have available if it was run as
> a normal cgi script.
>
> So, this lead me to mod_perl. Is mod_perl a solution in this case?
>
> If so, would it be a total replacement for the RewriteEngine in this example?
>
> Is there a mod_perl script/module that already does URI rewriting
> that I can use for reference?
>
> Or,
>
> Does anyone know how I could possibly make the %ENV available to
> foo.cgi in a case like the above?
>
> Thanks for any and all pointers if answering with ROTFM, please
> point me to a URL or chapter ;-)
>
> - Paul
> --
>
> - Kudosnet Technologies Inc. -
> Support: [EMAIL PROTECTED]
> Accounts: [EMAIL PROTECTED]
> Sales: [EMAIL PROTECTED]
> 1-877-885-8367 --
--
Sean Chittenden[EMAIL PROTECTED]
PGP signature
Re: mod_perl shared memory with MM
Sorry for taking a while to get back to this, road trips can be good at interrupting the flow of life. It depends on the application. I typically use a few instances of open() for the sake of simplicity, but I have also had decent luck with IPC::Open(2|3). The only problems I've had with either was an OS specific bug with Linux (the pipe was newline buffering and dropping all characters over 1023, moved to FreeBSD and the problem went away). Words of wisdom: start slow because debugging over a pipe can be a headache (understatement). Simple additions + simple debugging = good thing(tm). I've spent too many afternoons/nights ripping apart these kinds of programs only to find a small type-o and then reconstructing a much larger query/response set of programs. -sc PS You also want to attach the program listening to the named pipe to something like DJB's daemon tools (http://cr.yp.to/daemontools.html) to prevent new requests from blocking if the listener dies: bad thing(tm). On Wed, Feb 28, 2001 at 10:23:06PM -0500, Adi Fairbank wrote: > Delivered-To: [EMAIL PROTECTED] > Date: Wed, 28 Feb 2001 22:23:06 -0500 > From: Adi Fairbank <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) > X-Accept-Language: en > To: Sean Chittenden <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > Subject: Re: mod_perl shared memory with MM > > Sean, > > Yeah, I was thinking about something like that at first, but I've never played > with named pipes, and it didn't sound too safe after reading the perlipc man > page. What do you use, Perl open() calls, IPC::Open2/3, IPC::ChildSafe, or > something else? How stable has it been for you? I just didn't like all those > warnings in the IPC::Open2 and perlipc man pages. > > -Adi > > Sean Chittenden wrote: > > > > The night of Fat Tuesday no less... that didn't help any > > either. ::sigh:: > > > > Here's one possibility that I've done in the past becuase I > > needed mod_perl sessions to be able to talk with non-mod_perl > > programs. I setup a named bi-directional pipe that let you write a > > query to it for session information, and it wrote back with whatever > > you were looking for. Given that this needed to support perl, java, > > and c, it worked _very_ well and was extremely fast. Something you > > may also want to consider because it keeps your session information > > outside of apache (incase of restart of apache, or desire to > > synchronize session information across multiple hosts). > > > > -sc > > > -- Sean Chittenden[EMAIL PROTECTED] PGP signature
Re: mod_perl shared memory with MM
The night of Fat Tuesday no less... that didn't help any either. ::sigh:: Here's one possibility that I've done in the past becuase I needed mod_perl sessions to be able to talk with non-mod_perl programs. I setup a named bi-directional pipe that let you write a query to it for session information, and it wrote back with whatever you were looking for. Given that this needed to support perl, java, and c, it worked _very_ well and was extremely fast. Something you may also want to consider because it keeps your session information outside of apache (incase of restart of apache, or desire to synchronize session information across multiple hosts). -sc On Wed, Feb 28, 2001 at 09:25:45PM -0500, Adi Fairbank wrote: > Delivered-To: [EMAIL PROTECTED] > Date: Wed, 28 Feb 2001 21:25:45 -0500 > From: Adi Fairbank <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) > X-Accept-Language: en > To: Sean Chittenden <[EMAIL PROTECTED]> > Subject: Re: mod_perl shared memory with MM > > It's ok, I do that a lot, too. Usually right after I click "Send" is when I > realize I forgot something or didn't think it through all the way. :) > > Sean Chittenden wrote: > > > > Hmm... yeah, whoops. I suppose that's what I get for sending > > email that late. <:~) -sc > > > -- Sean Chittenden[EMAIL PROTECTED] C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD PGP signature
Re: mod_perl shared memory with MM
> > Is there a way you can do that without using Storable?
>
> Right after I sent the message, I was thinking to myself that same
> question... If I extended IPC::MM, how could I get it to be any
> faster than Storable already is?
You can also read in the data you want in a startup.pl file
and put the info in a hash in a global memory space
(MyApp::datastruct{}) that gets shared through forking (copy on write,
not read, right?). If the data is read only, and only a certain size,
this option has worked _very_ well for me in the past. -sc
--
Sean Chittenden[EMAIL PROTECTED]
C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD
PGP signature
Re: dynamically output messages on browser.
> I wrote perl script to out put messages. It is supposed to output one > line per 4 seconds. while loop has sleep(4), then print messages until > all messages print out. > > But the server did not output the result per 4 seconds instead output > all of results after 40 seconds How can I control that. Thanks. Apache is buffering the output. Put a "\n" at the end of your print statements and you should be okay, or an alternative would be to use $r->rflush after each print statement. -sc -- Sean Chittenden
mod_perl jobs...
Howdy. I received notice of some mod_perl positions earlier today and think that there are some people on the list who may bite at the opportunity. Here's the gist of it: Summary:5-10 moderate-advanced mod_perl programmers Skills: 1) Familiarity with mod_perl and the Apache request cycle (requirement) 2) Knows core perl areas very well (ex: file i/o, modules) 3) Basic SQL (sophisticated SQL knowledge a bonus) for MySQL or Oracle Extras: 1) Large regexp's 2) IO::Socket (network programming) 3) DBI (closer to a requirement, but still optional) Telecommuting: "Option for a strong Senior self-managing candidate" If you have an interest in the previous, please send me either an e-mail of interest, or a resume. The primary place of work will be in the Bay Area (Mountain View), but there are telecommuting possibilities. The company that I am relaying this for is a startup and has received funding. Like the summary said though, looking for 5-10 people who'd be interested. Send me an e-mail and I'll send you more details. If you think you know of someone who'd fit the criteria, forward them a copy of this. Thanks. --SC -- Sean Chittenden <[EMAIL PROTECTED]>
Re: PerlChildInitHandler
Lol! I ripped that right out of Apache::Status. Any ideas as to
whether or not its faster with map or push? I may, desire dependent,
benchmark the two formats and report the results.
It looks to me like the reason Doug did the code the way he did
was because he returns an array ref to the calling sub. --SC
PS CGI.pm does not reside on my system because of it's HTML
generation capabilities (and the consiquent memory bloat). ;)
On 14 Feb 2000, Randal L. Schwartz wrote:
> Date: 14 Feb 2000 09:35:06 -0800
> From: Randal L. Schwartz <[EMAIL PROTECTED]>
> To: Sean Chittenden <[EMAIL PROTECTED]>
> Cc: Brendan W. McAdams <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: PerlChildInitHandler
>
> >>>>> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>
> Sean> Check to make sure that you compiled in the Init and Exit handlers
> Sean> into mod_perl.
>
> Sean> If you include the following code in a script, you should be able
> Sean> to figure this out really quick:
>
> Sean> require mod_perl;
> Sean> require mod_perl_hooks;
> Sean> my @retval = qw();
> Sean> my @list = mod_perl::hooks();
> Sean> for my $hook (sort @list) {
> Sean> my $on_off =
> Sean> mod_perl::hook($hook) ? "Enabled" : "Disabled";
> Sean> push @retval, "$hook$on_off\n";
> Sean> }
> Sean> push @retval, qw();
>
> Sean> print @retval;
>
> Ewww... Too many pushes. :)
>
> require mod_perl;
> require mod_perl_hooks;
> print "",
> (map {
> "", $_, "",
> (mod_perl::hook($_) ? "Enabled" : "Disabled"),
> "\n" } mod_perl::hooks()),
> "";
>
> map is your friend. Of course, this would have been even simpler with
> CGI.pm HTML generators. :)
>
>
--
Sean Chittenden
[EMAIL PROTECTED]
(408)530-0001
Re: PerlChildInitHandler
It's a bit harsh, but I'd try something like this just for kicks
to make sure I can get access to the requested Handler.
# In httpd.conf
PerlModule DieOnInit
# In DieOnInit package
package DieOnInit;
sub handler {
warn "Child $$ is going to die in 20 seconds";
sleep(20); # Prevents children from constantly dying and filling up the
# error logs
die "Child dead: $$";
}
1;
#-- End package
I have a variation of this module lying around someplace that
provides me with a sanity check with regards to programming. If the child
dies, then the code is executed and I can plop in my ___ number of lines
of code that weren't being executed earlier. This kind of approach is
pretty top-down, but works when setting apache up... I've had a few
instances where the child _wasn't_ dying because of a config problem
farther up in the conf file.
At any rate, let me know if the handler isn't being executed... and
what you're trying to execute for that matter. Could you use a
PerlRequire directive and place your init stuff in there? --SC
On Mon, 14 Feb 2000, Brendan W. McAdams wrote:
> Date: Mon, 14 Feb 2000 12:25:30 -0500
> From: Brendan W. McAdams <[EMAIL PROTECTED]>
> To: Sean Chittenden <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: PerlChildInitHandler
>
> Yup.
> (I knew i did since i compiled with EVERYTHING=1).
>
>
> All handlers lists as Enabled when this script is run.
>
> So ... whats the next step in debugging here?
>
> -brendan
> -
> Brendan W. McAdams| email: [EMAIL PROTECTED]
> Programmer/Systems Administrator | office: (305)377-2880
> Plexus InterActive| pager: (305)277-4879
> http://www.plexmedia.com | cell phone: (305)401-7313
>
>
> "Always listen to the experts - they'll tell you what can't be done and why.
> Then do it."
> -Robert A. Heinlein
> - Original Message -
> From: "Sean Chittenden" <[EMAIL PROTECTED]>
> To: "Brendan W. McAdams" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, February 14, 2000 12:17 PM
> Subject: Re: PerlChildInitHandler
>
>
> Check to make sure that you compiled in the Init and Exit handlers
> into mod_perl.
>
> If you include the following code in a script, you should be able
> to figure this out really quick:
>
> require mod_perl;
> require mod_perl_hooks;
> my @retval = qw();
> my @list = mod_perl::hooks();
> for my $hook (sort @list) {
> my $on_off =
> mod_perl::hook($hook) ? "Enabled" : "Disabled";
> push @retval, "$hook$on_off\n";
> }
> push @retval, qw();
>
> print @retval;
>
>
> Credit goes to Doug MacEachern on the code. Stick that chunket of
> code in a script and it should let you know what you have available and
> what you don't. ;) --SC
>
>
> On Mon, 14 Feb 2000, Brendan W. McAdams wrote:
>
> > Date: Mon, 14 Feb 2000 12:02:45 -0500
> > From: Brendan W. McAdams <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: PerlChildInitHandler
> >
> > I'm having trouble getting apache to even recognise the existance of
> > PerlChildInitHandler ( and childexithandler it seems as well) .
> >
> > I've tried declaring my PerlChildInitHandler inside a VirtualHost, in the
> > main body of the config, and as a push_handler in my startup file [which
> is,
> > i know for a fact, being execed].
> >
> > no matter what I try, apache is compeltely ignoring this directive.
> > I've put write to log when initialised traps in the modules that are being
> > handled on init and they never trip.
> >
> > I've tried this with both Apache 1.39/modperl1.19 and Apache
> > 1.311/modperl1.21 and no luck
> > Any assistance would be greatly appreciated.
> >
> > Brendan
> > -----
> > Brendan W. McAdams| email: [EMAIL PROTECTED]
> > Programmer/Systems Administrator | office: (305)377-2880
> > Plexus InterActive| pager: (305)277-4879
> > http://www.plexmedia.com | cell phone: (305)401-7313
> >
> >
> > "Always listen to the experts - they'll tell you what can't be done and
> why.
> > Then do it."
> > -Robert A. Heinlein
> >
> >
>
> --
> Sean Chittenden
> [EMAIL PROTECTED]
> (408)530-0001
>
>
>
--
Sean Chittenden
[EMAIL PROTECTED]
(408)530-0001
Re: PerlChildInitHandler
Check to make sure that you compiled in the Init and Exit handlers
into mod_perl.
If you include the following code in a script, you should be able
to figure this out really quick:
require mod_perl;
require mod_perl_hooks;
my @retval = qw();
my @list = mod_perl::hooks();
for my $hook (sort @list) {
my $on_off =
mod_perl::hook($hook) ? "Enabled" : "Disabled";
push @retval, "$hook$on_off\n";
}
push @retval, qw();
print @retval;
Credit goes to Doug MacEachern on the code. Stick that chunket of
code in a script and it should let you know what you have available and
what you don't. ;) --SC
On Mon, 14 Feb 2000, Brendan W. McAdams wrote:
> Date: Mon, 14 Feb 2000 12:02:45 -0500
> From: Brendan W. McAdams <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: PerlChildInitHandler
>
> I'm having trouble getting apache to even recognise the existance of
> PerlChildInitHandler ( and childexithandler it seems as well) .
>
> I've tried declaring my PerlChildInitHandler inside a VirtualHost, in the
> main body of the config, and as a push_handler in my startup file [which is,
> i know for a fact, being execed].
>
> no matter what I try, apache is compeltely ignoring this directive.
> I've put write to log when initialised traps in the modules that are being
> handled on init and they never trip.
>
> I've tried this with both Apache 1.39/modperl1.19 and Apache
> 1.311/modperl1.21 and no luck
> Any assistance would be greatly appreciated.
>
> Brendan
> -
> Brendan W. McAdams| email: [EMAIL PROTECTED]
> Programmer/Systems Administrator | office: (305)377-2880
> Plexus InterActive| pager: (305)277-4879
> http://www.plexmedia.com | cell phone: (305)401-7313
>
>
> "Always listen to the experts - they'll tell you what can't be done and why.
> Then do it."
> -Robert A. Heinlein
>
>
--
Sean Chittenden
[EMAIL PROTECTED]
(408)530-0001
Re: emulating Basic Auth from Mason
I'm assuming that you're doing this in an access handler. If that's the case, set up some condition in your module where it figures out whether or not the user is authenticated. If the user isn't authenticated: return(AUTH_REQUIRED); That should do it. I don't think that'll return the error page stating that you need access to continue, instead that should pass a header (I think two actually) to the browser signaling it to prompt the user. Another alternative would be to have the user redirected to a login page with good old fashion forms. ;) Good luck. --SC PS If you're really interested in details of this, check out: <http://www.modperl.com/book/chapters/ch6.html> -- Sean Chittenden On 13 Feb 2000, Louis-David Mitterrand wrote: > Date: 13 Feb 2000 14:09:08 - > From: Louis-David Mitterrand <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: emulating Basic Auth from Mason > > I have this component which both displays and updates a database. > > If the user wants to update a record I'd like the following to happen: > > 1) detect in the component that a DB update is attempted, > > 2) check if the user is already logged in by checking for login/password > presence in the Apache::Session %session hash, > > 3) if not, then instruct Apache to return a Basic Auth dialog prompting > for login/password, > 3.1) get the login/password from the $r object and store it in > %session, > > The tough part (and this is where a lack of mod_perl experience shows) > is: how do I tell Apache put itself in "Basic Auth mode" so that it will > prompt the user for his login/password? And it has to work in a Mason > environment. > > I am digging into the mod_perl Guide at present for hints, but if > someone could give me just a quick shove up the learning curve it would > really help. > > Thanks in advance, > > -- Sean Chittenden [EMAIL PROTECTED] (408)530-0001
Re: XML Configuration [Was: Re: Caucho faster than mod_perl?]
Personally, I don't care. A conf file is a conf file. From the advocacy standpoint, I think it's probably a smart move on the part of mod_perl/httpd developers. There is a HUGE value in hyped up techologies with upper management. I wish I were kidding when I say that in the past I have seen several managers choose utilities because they have XML configurations (or some swift GUI, etc.). The product, in four of the six instances, turned out to be a nightmarish hell that entailed many sleepless nights on the phone with the Exodus NOCies talking them through how to coach servers back to life (mod_perl to the rescue!!!). Anyway, I think this would be pretty groovin' and would lend itself to a "public friendly" system that would sell better, which, seems to be mod_perls big problem (IMHO). Programmers are doing the marketing/advertising, etc... managers, who make the decissions listen to non-techies (typically) and are going w/ Java. The question remains then, what part of the config outside of the httpd.conf could be put into an XML config? --SC On Wed, 02 Feb 2000, Matt Sergeant wrote: > On Wed, 02 Feb 2000, Perrin Harkins wrote: > > > I'm not trying to belittle Resin in any way -- in fact I'm impressed by > > > both its design and performance. In learning about Resin during these > > > tests, I found that JSP is in many ways easier to use than mod_perl. The > > > smart caching that Resin does (with compiling .java -> .class, etc.) is > > > effective, and the XML configuration is a joy to deal with compared to > > > Apache's httpd.conf. > > Actually what interests me more about this benchmark (which as you say - > are starting to get meaningless now anyhow) is the XML configuration. Would > people prefer to setup mod_perl using some sort of XML configuration, > because I might be interested in doing this, if there's interest. > > Also, what's different between Resin's smart caching and mod_perl's? Is it > just like StatINC? > > -- > > > Details: FastNet Software Ltd - XML, Perl, Databases. > Tagline: High Performance Web Solutions > Web Sites: http://come.to/fastnet http://sergeant.org > Available for Consultancy, Contracts and Training.
Caucho faster than mod_perl?
Hey. This is kind of relevant regarding the latest hello benchmarks that were released. I was sent this today and thought it would be of some interest to you guys, or at least those interested in benchmarks. <http://www.caucho.com/articles/benchmark.html> Supposedly, according to its benchmarks, it's faster than mod_perl... impressive to say the least. Any chance someone has any experience with this or would like to benchmark this technology? External validation would be pretty useful. --SC -- Sean Chittenden
$r->filename and Apache::RegistryBB...
Howdy. Here's the background: In my Transhandler, I'm setting the URI
and setting the filename for use. The filename is executed by
Apache::RegistryBB, code cached, etc Things run smoothly until I ask a
process for the file again things get ugly fast.
The error messages I'm getting are:
[Tue Feb 1 12:02:36 2000] [error] Can't upgrade that kind of scalar at
/usr/lib/perl5/site_perl/5.005/i686-linux-thread/Apache/RegistryBB.pm line 20.
Attempt to free unreferenced scalar.
[Tue Feb 1 12:02:30 2000] [notice] child pid 31687 exit signal Segmentation
fault (11)
Attempt to free unreferenced scalar at
/usr/lib/perl5/site_perl/5.005/i686-linux-thread/Apache/PerlRun.pm line 256.
The only commonality through out this is the filename. In my
transhandler I'm setting the filename and returning OK:
$r->filname('/www/docs/login' . $uri());
return(OK);
I'm pretty sure that's not the problem, but I could be wrong. I do
know that when I stop using Apache::RegistryBB and use plain old Registry,
things work with out a hitch, no segfaults in sight. Any thoughts/ideas?
perl, version 5.005_03 built for i686-linux-thread
Server version: Apache/1.3.11 (Unix)
Server built: Jan 25 2000 16:25:14
mod_perl, 1.21
--
Sean Chittenden p. 650.473.1805
auctia.com, Inc.f. 650.329.9651
Apache::RegistryBB
I was looking through Registry and RegistryBB today and noticed something that strikes me as broken. In Apache::RegistryBB when you access a directory it returns FORBIDDEN, but in Registry it returns DECLINED. The consiquenses of this seem pretty broken and backwards to the "Apache/mod_perl way" of things, but maybe that's just me. Anybody care to comment as to why this is? Any chance of getting the official source changed to return DECLINED instead of FORBIDDEN? --SC -- Sean Chittenden p. 650.473.1805 auctia.com, Inc.f. 650.329.9651
Re: overriding document root dynamically?
This is more along the lines of a cautionary note than anything else,
but mod_perl isn't exactly a secure system, so I'd be very carefull with this
setup: if you're doing what I think you're doing. Do you trust your users? Are
the allowed to execute perl-code? If so, they could gain access to other
people's files in their www directory.
Are there any modules that are similar to user_dir that are more
configurable? --SC
On Fri, 28 Jan 2000, Jonathan Swartz wrote:
> I have an application where I want the effective DocumentRoot to change
> based on dynamic properties in the request.
>
> In particular, we are creating a number of domain aliases, pointing to the
> same IP address, so that each user can view their own version of the web
> site. e.g.
>
>joe.dev.mysite.com would have doc root /home/joe/www
> dave.dev.mysite.com would have doc root /home/dave/www
>
> etc. I could do this with a set of virtual servers, but then I have to
> change the httpd.conf and restart the server every time a user is
> added, which is undesirable.
>
> Here's what I wanted to work:
>
> sub trans_handler
> {
> my ($r) = @_;
> my ($user) = ($r->header_in('Host') =~ /^[^\.]+/);
> $r->document_root("/home/$user/www");
> return DECLINED;
> }
>
> PerlTransHandler trans_handler
>
> but I got
>
> [error] Usage: Apache::document_root(r) at handler.pl line 41
>
> so document_root ain't writable.
>
> Any other suggestions? I'm loathe to recreate the entire default Apache
> directory handler in my trans_handler (looking for index.html, etc.)
>
> Jon
--
Sean Chittenden p. 650.473.1805
auctia.com, Inc.f. 650.329.9651
Re: how come httpd doesn't start even though startup.pl is fine?
Something is tickling the back of my mind regarding this. I think it's because Red Hat includes a botched perl build (ie different install options). A while back I took to rebuilding perl by hand and haven't had this problem in a _long_ time. I'd try going that route if your problems persist. This still strikes me as a work around and not necessarily a solution, but I haven't spent the time to figure out the specific prob w/ Red Hat's build, so workarounds are legit. ::grin:: Plus, depending on your needs, the build flag -O6 always helps too ;) -- Sean Chittenden <[EMAIL PROTECTED]> I may be getting older, but I refuse to grow up! On Fri, 14 Jan 2000, Clayton Cottingham wrote: > Date: Fri, 14 Jan 2000 19:58:35 + > From: Clayton Cottingham <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: how come httpd doesn't start even though startup.pl is fine? > > ok, i think if you mean redhat 6.1 as opposed to linux6.1 i have the same prob, > > i have never been able to insert anything into the startup.pl > besides Apache CGI CGI::Carp . > if i try to add any third parties it dies > > i did a quick search on the mail list and the red hat updates and found that > they both pointed to the fact that apache is not compiled right to use dso's > > noteable i think it was with apxs > > go to > ftp://ftp.redhat.com/pub/redhat/updates/6.1/i386/ > for the new apache > > i havent yet tried this please if anyone else has any info please let me know > > i know apache dso w modperl works fine, i compiled em mysef on stampede! > > ttfn
Re: how come httpd doesn't start even though startup.pl is fine?
Drat... I was kinda hoping that would've been it. Oh
well Alright, how about this:
1) Set your logging level to debug (is it right now? I bet not)
2) Wrap your startup.pl file in some tags in your
httpd.conf file and eval the code. See if it sets $@. If so, then print
the result. Another thing you could do is install a signal handler for
$SIG{DIE} and print a stack trace using Carp::Croak. I've had to do the
latter more times than I care to admit, but it works really well in
catching errors.
I'd try #1, personally (much easier). --SC
--
Sean Chittenden <[EMAIL PROTECTED]>
Don't buy a landslide. I don't want to have to pay for one more vote
than I have to.
-- Joseph P. Kennedy, on JFK's election strategy.
On Fri, 14 Jan 2000, Ricardo Kleemann wrote:
> Date: Fri, 14 Jan 2000 07:59:39 -0800 (PST)
> From: Ricardo Kleemann <[EMAIL PROTECTED]>
> To: Sean Chittenden <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: how come httpd doesn't start even though startup.pl is fine?
>
> Thanks but unfortunately that's not it... :-(
>
> I only put in a snippet of the startup.pl. My file does indeed have a 1;
> at the bottom...
>
> Ricardo
>
> On Fri, 14 Jan 2000, Sean Chittenden wrote:
>
> > You're going to love this... your startup.pl file is
> > fine... almost. You're forgetting a key part of the script... issue this
> > shell command and it'll work:
> >
> > echo "1;" >> startup.pl
> >
> >
> > The startup script needs to return true from its
> > eval. <:)
> >
> > --SC
> >
> > --
> > Sean Chittenden <[EMAIL PROTECTED]>
> >
> > What you don't know won't help you much either.
> > -- D. Bennett
> >
> > On Thu, 13 Jan 2000, Ricardo Kleemann wrote:
> >
> > > Date: Thu, 13 Jan 2000 16:47:35 -0800 (PST)
> > > From: Ricardo Kleemann <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: how come httpd doesn't start even though startup.pl is fine?
> > >
> > > Hi everyone,
> > >
> > > I don't know what's causing this, and there are no errors being logged in
> > > my error_log.
> > >
> > > I'm running apache 1.3.9, mod_perl 1.21, linux 6.1
> > >
> > > I have a startup.pl with a bunch of modules in it. If I run the startup.pl
> > > by itself it is fine, does not report errors... however, if I run httpd it
> > > dies, never gets off the ground. If I go thru my list of modules and
> > > remove some of them, then everything starts up fine...
> > >
> > > Here's my list: the ones commented out will cause httpd to not startup...
> > > IF I leave the list as is, it starts up fine. If I uncomment any one of
> > > these, httpd doesn't complain, doesn't log anything, but never starts up
> > > correctly
> > >
> > > use CGI ();
> > > #use Fcntl;
> > > #use IO::ScalarArray;
> > > use Time::Zone;
> > > #use MD5;
> > > use LWP::Simple;
> > > #use LWP::UserAgent;
> > > use Date::Parse;
> > > #use MIME::Head;
> > > #use MIME::Body;
> > > #use MIME::Entity;
> > > #use MIME::Parser;
> > > #use Data::Dumper;
> > > use Mail::Address;
> > > #use HTML::Parse;
> > > #use Net::SMTP;
> > >
> > >
> >
> >
>
>
$r->notes()...
If I use $r->notes in a mod_perl handler, is it accessible via the
core apache request object in other non-perl modules?
$r->notes('foo','bar');
Is the value of notes stored in the core apache process and if so,
is it accessible by other modules by their similar r->notes methods (ie,
mod_java or some custom C module)? If not, why not? I wouldn't expect to
be able to store hashes, etc (use a global var, such as
$sitename::globalvar for that), but strings?
My question being stemmed from the possibility of having to use
mod_java and mod_perl on the same server and getting the two to talk to
each other in a friendly manner. Anyone have any experience w/ this or
tips w/ regards to the best way of going about this kind of a setup?
--
Sean Chittenden <[EMAIL PROTECTED]>
VMS, n:
The world's foremost multi-user adventure game.
Re: how come httpd doesn't start even though startup.pl is fine?
You're going to love this... your startup.pl file is fine... almost. You're forgetting a key part of the script... issue this shell command and it'll work: echo "1;" >> startup.pl The startup script needs to return true from its eval. <:) --SC -- Sean Chittenden <[EMAIL PROTECTED]> What you don't know won't help you much either. -- D. Bennett On Thu, 13 Jan 2000, Ricardo Kleemann wrote: > Date: Thu, 13 Jan 2000 16:47:35 -0800 (PST) > From: Ricardo Kleemann <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: how come httpd doesn't start even though startup.pl is fine? > > Hi everyone, > > I don't know what's causing this, and there are no errors being logged in > my error_log. > > I'm running apache 1.3.9, mod_perl 1.21, linux 6.1 > > I have a startup.pl with a bunch of modules in it. If I run the startup.pl > by itself it is fine, does not report errors... however, if I run httpd it > dies, never gets off the ground. If I go thru my list of modules and > remove some of them, then everything starts up fine... > > Here's my list: the ones commented out will cause httpd to not startup... > IF I leave the list as is, it starts up fine. If I uncomment any one of > these, httpd doesn't complain, doesn't log anything, but never starts up > correctly > > use CGI (); > #use Fcntl; > #use IO::ScalarArray; > use Time::Zone; > #use MD5; > use LWP::Simple; > #use LWP::UserAgent; > use Date::Parse; > #use MIME::Head; > #use MIME::Body; > #use MIME::Entity; > #use MIME::Parser; > #use Data::Dumper; > use Mail::Address; > #use HTML::Parse; > #use Net::SMTP; > >
Re: Embperl emergency
print qq(Using qq() works remarkably well and preserves newlines,
tabs, etc. Here docs are... legacy, in my mind and are less friendly to
editors (such as emacs). See if moving to qq() solves your problems, if
not, then ... I dunno.);
This is more along the lines of a PS than anything else, but it
works for all interpolated envs in perl. Ex:
print qq(the result of 1 + 1 = @{[1 + 1]}\n);
Inline code evaluation w/in a string... combine this w/ the
ternery operator ((EXPR) ? (TRUE) : (FALSE)) and you've got a pretty
inline scripting tool that's not emb perl. The only gotcha is that you
can't have multiple statements (ex: @{[ EXPR; EXPR2; EXPR3 ]}). That
should turn up an error. Anyway, fyi.
--SC
--
Sean Chittenden <[EMAIL PROTECTED]>
My CODE of ETHICS is vacationing at famed SCHROON LAKE in upstate New
York!!
On Thu, 13 Jan 2000, Chris wrote:
> Date: Thu, 13 Jan 2000 07:55:36 +1100
> From: Chris <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Embperl emergency
>
>
> Hi,
>
> I've just upgraded to Embperl 1.2.1 and I've stuffed my webserver. It
> appears the problem is that I've been writing code like this..
> print <
> EOF
>
> This used to work, but I guess it's wrong. I've tried $optRedirectStdout
> but it quotes everything...
> <HTML> which is not what I want.
> I've tried $optDisableHtmlScan, but that doesn't seem to help in this
> case.
>
> The code in question is in another perl module that doesn't seem to have
> access to OUT, so I can't print to that. I've tried passing OUT as a
> parameter to the subroutine (\*OUT or *OUT{IO}) but I can't seem to get
> the syntax right or something because it just complains that $OUT is
> undefined.
>
> Can someone help get my webserver back on line!?
>
> Thanks,
>
> Chris Bitmead
> mailto:[EMAIL PROTECTED]
>
Re: problems with module at root of web site
Mind if I ask a nit-pick of a performance question? Currently
speed and performance are of upmost importance (I'm currently involved in
a mod_perl vs JServ development race). That being said, isn't pushing a
handler onto the request stack slower than predefining a handler that the
request falls through to? I could be wrong and haven't tested things
otherwise, but, it would seem like pushing a custom handler (granted it's
already compiled into byte-code) onto the stack at the time of the request
would take slightly longer. I suppose I'd be who of me to test this
assertion, but if you have any idea as to wether or not this case ahead of
time, I'd be greatly interested in hearing about your past experience.
--Sean
--
Sean Chittenden <[EMAIL PROTECTED]>
On 12 Jan 2000, Randal L. Schwartz wrote:
> Date: 12 Jan 2000 07:33:36 -0800
> From: Randal L. Schwartz <[EMAIL PROTECTED]>
> To: Sean Chittenden <[EMAIL PROTECTED]>
> Cc: Etienne Pelaprat <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: problems with module at root of web site
>
> >>>>> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>
> Sean> There are a few ways to go about this one, but here's the solution
> Sean> that I'd use.
>
> Sean> 1) Install a PerlTransHandler that sets the URI to / or whatever
> Sean> you want to have your PerlHandler work with. Have the transhandler return
> Sean> DECLINED if $r->uri =~ m:^/images/:o;
>
> Sean> 2) Install a PerlHandler that builds the response for the web.
>
> Or a variation of that, that I like... set up a TransHandler like this:
>
> sub handler { # PerlTransHandler
> return DECLINED unless $r->uri eq "/";
> $r->set_handler("perl-script");
> $r->push_handlers( PerlHandler => sub {
> ... your code goes here
> }
> return OK;
> }
>
> No need to mess with $r->uri, which will be very confusing if there's
> an error.
>
>
> Sean> The advantage to doing it this way is:
>
> Sean> a) this was what apache was designed for (multiple phases)
> Sean> b) allows other handlers to kick in before you build the response
> Sean> (such as mod_access)
>
> Absolutely.
>
>
Re: problems with module at root of web site
There are a few ways to go about this one, but here's the solution that I'd use. 1) Install a PerlTransHandler that sets the URI to / or whatever you want to have your PerlHandler work with. Have the transhandler return DECLINED if $r->uri =~ m:^/images/:o; 2) Install a PerlHandler that builds the response for the web. The advantage to doing it this way is: a) this was what apache was designed for (multiple phases) b) allows other handlers to kick in before you build the response (such as mod_access) -- Sean Chittenden <[EMAIL PROTECTED]> Power tends to corrupt, absolute power corrupts absolutely. -- Lord Acton On Wed, 12 Jan 2000, Etienne Pelaprat wrote: > Date: Wed, 12 Jan 2000 01:50:49 PST > From: Etienne Pelaprat <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: problems with module at root of web site > > Hi, > > I have written a perl module that is meant to run at the root of a web > site (blah.com/, let's say), but there are errors whenever it tries to > access an image with an absolute URL. For instance, this tag returns a > broken image: > > > > this, I'm guessing, is because it's using in some way or another the > module I have written, since it's pointing from root. How do I fix > this? How do I make the module act at the root of the site and not > have it interfere with absolute URIs like that? > > Regards, > > Etienne >
Dedicated dynamic content servers...
Is it possible to 'short circuit' some of the request handlers in apache? I'm building a dedicated dynamic content server that is getting some really bizarre input through the URI and it doesn't map to a file, instead a Translation Handler deals with the request and sets some variables for an authorization handler that I have running later on. Because the one of the following core apache handlers checks $r->filename before my Auth handler runs... I get 404ed. What I can do is role all of my functionality into a single Trans handler, but that's no good and not something I'm interested in doing (bad programming, esp when you have LOTS of developers working on the same project). In a nut shell, how do I tell Apache that I don't want it to touch down on disk? Undef the filename or set the file name to /dev/zero? Thoughts? Bizarre, tweaky, strange, or hacked ideas that have been floating in the back of peoples' heads are okay and valid suggestions (either to me personally or to the list). I can make the ugliest of perl look legit, so I'm game for just about anything. --SC -- Sean Chittenden <[EMAIL PROTECTED]>
Re: Memory leak/server crashes
Yeah... two things I'd do: 1) Open two telnet sessions to the box. One for top that is monitoring processes for your web user (www typically) and is sorting by memory usage w/ a 1 second refresh. I'd change the size of the window and make it pretty short so that the refreshes happen quicker, but that depends on your connection speed. The second telnet window is a window that tails your access log (tail -f). It sounds boring, but by watching the two, you should have an idea as to when the problem happens. 2) Open up and hack Apache::SizeLimit and have it do a stack dump (Carp::croak) of what's going on... there may be some clue there. Solution #1 will probably be your best bet... Good luck (cool site too!). --SC -- Sean Chittenden <[EMAIL PROTECTED]> fingerprint = 6988 8952 0030 D640 3138 C82F 0E9A DEF1 8F45 0466 The faster I go, the behinder I get. -- Lewis Carroll On Sun, 9 Jan 2000, James Furness wrote: > Date: Sun, 9 Jan 2000 21:47:03 - > From: James Furness <[EMAIL PROTECTED]> > Reply-To: James Furness <[EMAIL PROTECTED]> > To: Sean Chittenden <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Memory leak/server crashes > > > Try using Apache::SizeLimit as a way of controlling your > > processes. Sounds like a recursive page that performs infinite internal > > requests. > > Ok, sounds like a good solution, but it still seems to me I should be > eliminating the problem at the source. Any ideas as to how I could narrow > down the location of whatever's causing the recursion? > -- > James Furness <[EMAIL PROTECTED]> > ICQ #: 4663650
Re: Memory leak/server crashes
Try using Apache::SizeLimit as a way of controlling your
processes. Sounds like a recursive page that performs infinite internal
requests.
--
Sean Chittenden <[EMAIL PROTECTED]>
fingerprint = 6988 8952 0030 D640 3138 C82F 0E9A DEF1 8F45 0466
My mother once said to me, "Elwood," (she always called me Elwood)
"Elwood, in this world you must be oh so smart or oh so pleasant."
For years I tried smart. I recommend pleasant.
-- Elwood P. Dowde, "Harvey"
On Sun, 9 Jan 2000, James Furness wrote:
> Date: Sun, 9 Jan 2000 19:58:00 -
> From: James Furness <[EMAIL PROTECTED]>
> Reply-To: James Furness <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Memory leak/server crashes
>
> I'm looking for some help getting apache to run reliably. Apache 1.3.9 with
> mod_perl 1.21 and Perl 5.005_03 is running on a dual P500 with 1 Gb of RAM
> running Redhat 6.1. We run about 5 sites off the box, most of which are
> fairly high traffic, and use a lot of CGI and
> MySQL 3.22.25 is used with Apache::DBI.
>
> The major problem seems to be a memory leak of some sort, identical to that
> described in the "memory leak in mod_perl" thread on this list from October
> 1997 and the "httpd, mod_perl and memory consumption (long)" thread from
> July 1997.
>
> The server runs normally for several hours, then suddenly a httpd process
> starts growing exponentially, the swapfile usage grows massively and the
> server starts to become sluggish (I assume due to disk thrashing caused by
> the heavy swap usage). Usually when this started to happen I would log in
> and use apachectl stop to shutdown the server, then type 'killall httpd'
> several times till the processes finally died off, and then use apachectl
> start to restart apache. If I was not around or did not catch this, the
> server would eventually become unresponsive and lock up, requiring a manual
> reboot by the datacentre staff. Messages such as "Out of memory" and
> "Callback called exit" would appear in the error log as the server spiralled
> down and MySQL would start to have trouble running.
>
> To combat this, I created a script to monitor load and swapfile usage, and
> restart apache as described above if load was above 7 and swapfile usage
> above 150Mb. This script has kept the server online and we now have an
> uptime of something like 22 days (previously no more than 1 day), but the
> script is getting triggered several times a day and no more "Out of memory"
> messages are appearing, but the situation is not ideal.
>
> I have tried adding:
>
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> Carp::cluck "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> }
>
>
> As recommended by the developers guide, which flooded the error log with the
> text below being printed roughly once a second in the error log:
>
> -
> Apache=SCALAR(0x830937c) can't $UNIVERSAL::AUTOLOAD!
> Apache=SCALAR(0x8309364) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> --
>
> I've pretty much exhausted any ways I can think of to trace this problem,
> such as i've tried to eliminate memory leaks in code by removing some
> scripts from mod_perl and running them under mod_cgi and i've tried tweaking
> MaxRequestsPerChild both without any success.
>
> One thing that was mentioned in a previous thread was that using 'exit'
> could confuse perl, and exit() is used fairly heavily in the scripts since
> most are converted to mod_perl from standard CGIs, but i'd prefer not to
> have to remove these since the structure of the scripts is reliant on some
> form of exit statement. Is there some alternative to exit()?
>
> I've also had a look at some of the patches to Apache.pm and Apache.xs
> suggested in the previous threads, and these seem to have been incorporated
> into mod_perl 1.21.
>
> Are there any other solutions I could try to this problem? Does anyone know
> what might be causing this?
>
> The second problem I have is when loading pages, usually CGI, but I think
> this has happened on some static pages, what IE5 descr
