RE: RE: MSQL server has gone away ( Apache::AuthDBI.pm )
Hi, Could you send me your script so that I can try to write my own workaround. Is your script integrated within Apache::AuthDBI.pm ? Thanks Alain -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: mercredi, 31. janvier 2001 16:23 To: [EMAIL PROTECTED] Subject: Re: RE: MSQL server has gone away ( Apache::AuthDBI.pm ) I ran into a similar problem while using MySQL and Apache::AuthDBI. I had a remote MySQL server that my apache web server connected to and used for authentication. Every so often (no pattern to this) the connection to MySQL would drop but MySQL would still be functioning properly. The only way I was able to detect whether the connection to MySQL was viable was to write my own script that would attempt to reconnect to MySQL and attempt to execute an actual query. Pinging from MySQL = Apache wouldn't work. BTW, the symptom that would present itself when the connection dropped was that apache would max out and NO URL requests would be processed. Artero Alain [EMAIL PROTECTED] wrote: Is there someone using the combination DBI, AuthDBI and mSQL ? I am wondering whether the "ping method" for msql in DBD::Msql exists already. PS:Thanks for your answer Daniel. Alain -- === "If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows." -- Sun Microsystems CEO, Scott McNealy __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/
Re: [RFC] mod_perl Digest path...
On Fri, 2 Feb 2001, Stas Bekman wrote: On Tue, 30 Jan 2001, Geoffrey Young wrote: sorry again for all the confusion with this morning's digest (I do code more carefully than I write, really I do...) this does present the opportune time to ask the list about the future of this digest... currently, the digest does not have a HTML home. Matt at take23.org has graciously agreed to host it and work on the XML stylesheets required for the site. This is a very good thing - but unfortunately, there is no easy way to derive a decent plain text version from an XML base... thus, the move to take23.org may mean that the digest no longer appears on the list in plaintext, but merely as a posting with a link to the current version... how does this strike everyone? Why everybody tries to solve a problem that doesn't exist IMHO? Why sourcing in XML in first place. Just throw the email as currently generated by Geoff between PRE/PRE and that's it. That's what ApacheToday and other online zines do and it seems just fine. You're so 1990's Stas :-) I guess that the only issue are the hrefs, but I guess this can be easily converted with s/\[\d+\]/.../. Thats the main issue really, when you're talking about a thread, the [x] links can get quite hard to follow with all the scrolling you end up doing. But we do have it worked out now anyway, we just need to get an easyish interface for uploading new digests built. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Using modperl as an 'adaptor' front end to an app server.
Is anyone using modperl in a way that it acts as an adaptor/scheduler in front of an app server in a 3-tier application environment? Basically I have a vendor provided (with source however) adaptor that takes incoming requests to the webserver, and passes that request onto an any number of applications via a socket running on a different server. It handles failover from dead app instances, however not very well, and is a big pile of C code. It also has problems in that because Apache is not multithreaded, one child copy of that adaptor that has marked an app instance as dead can't let another child know about that dead instance. Before I reinvent this C wheel in modperl, has anyone done so already? -D -- Off the record, on the QT, and very hush-hush.
Re: Using modperl as an 'adaptor' front end to an app server.
Yes, we do this for several clients using SOAP as an RPC transport to Java middleware. I think you could pretty easily just use socket timeout setting to say that if you don't get a response back within a period of time that you fail over to another server. The downside for SOAP is that the connection is not a persistent socket. SOAP is a protocol running over HTTP so you may find it slower than sockets. However, for many applications it's fast enough. I've also used PL/RPC, but I can't say that I was very happy with the stability of the PL/RPC server but that was over a year ago. And it could have been due to some XS modules that were persistent in the PL/RPC server. Anyway, you should be able to implement your own custom handler to talk your proprietary socket protocol in mod_perl. Later, Gunther At 10:28 PM 2/1/2001 -0800, Daniel Sully wrote: Is anyone using modperl in a way that it acts as an adaptor/scheduler in front of an app server in a 3-tier application environment? Basically I have a vendor provided (with source however) adaptor that takes incoming requests to the webserver, and passes that request onto an any number of applications via a socket running on a different server. It handles failover from dead app instances, however not very well, and is a big pile of C code. It also has problems in that because Apache is not multithreaded, one child copy of that adaptor that has marked an app instance as dead can't let another child know about that dead instance. Before I reinvent this C wheel in modperl, has anyone done so already? -D -- Off the record, on the QT, and very hush-hush. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: Using modperl as an 'adaptor' front end to an app server.
Hi all, On Fri, 2 Feb 2001, Gunther Birznieks wrote: Anyway, you should be able to implement your own custom handler to talk your proprietary socket protocol in mod_perl. I did this last year for a Client in the Big Smoke. Only about twenty lines. Sorry, can't give a way any source - it's their property. 73, Ged.
Re: Using modperl as an 'adaptor' front end to an app server.
On Fri, Feb 02, 2001 at 06:44:07PM +0800, Gunther Birznieks wrote: Yes, we do this for several clients using SOAP as an RPC transport to Java middleware. Out of interest, are all these clients using different SOAP implementations on different platforms? We are designing a system that accepts XML messages from disparate sources and routes them to their destination based on content and are thinking of using SOAP to formalise the encoding method (transportation is via HTTP), yet I keep reading about issues with interoperability between different SOAP implementations which defeats the purpose as far as I'm concerened. Any experiences in this area appreciated. (Off-list?) Regards, Martin
Re: Object-XML serialization [was Re: AxKit Users?]
On Wed, Jan 31, 2001 at 03:03:56AM +0100, Robin Berjon wrote: Alzabo (which is somewhat the opposite of Tangram) is designed with mod_perl in mind. XML serialization will be coming real soon now (as soon as Barrie Slaymaker finishes work on DBML). Cool. More pressure ;-). Anyway, we're just about through the "beta gauntlet" and I'll be able to get DBML packaged. Anyone that wants a tarball, just ask. - Barrie
Re: Best GCC compiler options for Intel (perl apache)
[Thanks for all the feedback on this from everyone.] On Thu, Feb 01, 2001 at 05:20:11PM +, G.W. Haywood wrote: The compiler isn't the place to look for performance gains. Look to your system architecture, Perl code. See if you can code the things that get executed the most in C. Use handlers, not Registry. Cache. Use RAID. Throw away your database. Well maybe not throw it away, but be careful how you use it. (I can't believe I'm saying this to you:). Remember the Pareto Principle. Believe me when I say that we've gone along way down those roads before wanting to squeeze a little more from the compiler. Tim.
Apache::ASP installation problem
Hi, I am using Apache 1.3.14 with mod_perl-1.24_01 on Solaris system The Apache/Mod_perl part of build is working fine. But when I installed Apache-ASP-2.07, during the make test part I got Undefied Routine Devel/Symdump error therefore the make test failed. So, I download and try to install Devel-Symdump-2.00, the make test failed with error code 29 on Command failed for target 'test-dynamic' Any person can provide any assistance will be appreciated. Thanks PC
[OT] web games running under modperl
Hi, this is not directly modperl related, but it's for a project that will run under modperl. A client of mine wants to have all sorts of games on his website, some single player, some multiplayer. I have very little game programming experience and I don't really feel like reimplementing backgammon or chess :-) The good thing is that the games needn't have IA (people never play against a computer), they just need to know the rules and control display. I looked into CPAN and googled for that, and though there are a few first leads I couldn't go very far. So, does anybody know of some Perl libs or scripts that could be easily cleaned up to run as handlers for typical games (chess, checkers, backgammon, etc...) ? Thanks in advance, -- robin b. There's too much blood in my caffeine system.
Re: [OT] web games running under modperl
On Fri, 2 Feb 2001, Robin Berjon wrote: The good thing is that the games needn't have IA (people never play against a computer), they just need to know the rules and control display. I looked into CPAN and googled for that, and though there are a few first leads I couldn't go very far. So, does anybody know of some Perl libs or scripts that could be easily cleaned up to run as handlers for typical games (chess, checkers, backgammon, etc...) ? I know of a free perl implementation of chess. Downloadable at http://www.beholder.co.uk/chess/board.html Paul Edmondson, Software Engineer Yospace Ltd, 7 The Courtyard, High Street, Staines, UK, TW18 4DP Tel: +44 1784 466388 Fax: +44 1784 466387 WWW: http://www.yospace.com
RE: [OT] Dynamically changing current package
NewPackage will then contain all things in TestPackage
Then you can redefined everything in TestPackage without affecting
anything in NewPackage.
Actually it will, if you were to delete NewPackage, TestPackage would not
contain anything. Modifying 'thingys' in TestPackage would modify
NewPackage.
Actually I investigated this a little more and discovered some
strange things...
If you check out the results, copying the package at the package
level cause scalars to be redefined and subroutines to created as
references. Where as copying the the package at the glob level
caused the the subroutines to be redefined and the scalars to be
references...
I wonder if this is a problem with perl?
Robert Landrum
--- results ---
# perl n.pl 1
NewPackage::x was defined
NewPackage::june was defined
$NewPackage::x was set to 100
$Test::x now contains 100
Now Deleting Test package
Test::x was deleted from the STASH
Test::june was deleted from the STASH
$NewPackage::x was set to 100
$Test::x now contains 100
Now Listing NewPackage
NewPackage::x
NewPackage::june
Now Listing Test
# perl n.pl
NewPackage:: was defined as *{Test::}
$NewPackage::x was set to 100
$Test::x now contains 1
Now Deleting Test package
Test::x was deleted from the STASH
Test::june was deleted from the STASH
$NewPackage::x was set to 100
$Test::x now contains 1
Now Listing NewPackage
Now Listing Test
--- Contents of n.pl ---
#!/usr/bin/perl
package Test;
our $x = 1;
sub june {
}
package main;
if($ARGV[0]) {
for my $name (keys %{Test::}) {
*{"NewPackage::".$name} = *{"Test::".$name};
print "NewPackage::".$name." was defined\n";
}
print "\n";
} else {
*{NewPackage::} = *{Test::};
print "NewPackage:: was defined as \*{Test::}\n";
print "\n";
}
$NewPackage::x = 100;
print "\$NewPackage::x was set to $NewPackage::x\n";
print "\$Test::x now contains $Test::x\n";
print "\n";
print "Now Deleting Test package\n";
for my $name (keys %{Test::}) {
delete $Test::{$name};
print "Test::".$name." was deleted from the STASH\n";
}
print "\n";
print "\$NewPackage::x was set to $NewPackage::x\n";
print "\$Test::x now contains $Test::x\n";
print "\n";
print "Now Listing NewPackage\n";
for my $name (keys %{NewPackage::}) {
print "NewPackage::".$name."\n";
}
print "\n";
print "Now Listing Test\n";
for my $name (keys %{Test::}) {
print "Test::".$name."\n";
}
print "\n";
Re: Error reporting mod_perl 1.25 + apache 1.3.17
Hi there, On Fri, 2 Feb 2001, Vasily Petrushin wrote: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi Options given to mod_perl's Makefile.PL USE_DSO=1 EVERYTHING=1 Have you tried building static? Did you search the mod_perl Mailing List archives for "Solaris"? 73, Ged.
Re: Using modperl as an 'adaptor' front end to an app server.
Daniel A wild guess here but are you talking about WebObjects? On Fri, 02 Feb 2001 01:28, Daniel Sully wrote: Is anyone using modperl in a way that it acts as an adaptor/scheduler in front of an app server in a 3-tier application environment? I wrote a perl adaptor last year to sniff the traffic that the WebObjects adaptor was sending to the application instances. I don't have the source any more but as far as I can remember, it was only a few screensful of code. However, it wasn't a full implementation of the adaptor and didn't work with KeepAlive requests and so forth. Basically I have a vendor provided (with source however) adaptor that takes incoming requests to the webserver, and passes that request onto an any number of applications via a socket running on a different server. It handles failover from dead app instances, however not very well, and is a big pile of C code. It also has problems in that because Apache is not multithreaded, one child copy of that adaptor that has marked an app instance as dead can't let another child know about that dead instance. I have often dreamt of writing a drop-in mod_perl replacement for the WO adaptor... I have never worked anywhere where they didn't have trouble configuring the Apache adaptor, particularly if their webservers were running Linux. If you're interested in pursuing this, drop me a line and we can jam on the topic for a bit. I also know the guy who wrote the hairy C code and he might have some insight into how to reimplement it. Kyle -- [EMAIL PROTECTED]
RE: [OT] Dynamically changing current package
Probably just never assumed to be used this way. Do not see to much
documentation on using the Symbol table directly. Here is something strange
as well. Try copying a package and then creating an object from it . . .
Really funky
Think I might post this to the p5p list
-
#!/usr/bin/perl -w
#
## ASSIGN TEST TO TEST2
*{ 'Test2::' } = *{ 'Test::' };
## LETS CREATE SOME OBJECTS
my $obj = Test-new;
print 'TEST PACKAGE OBJECT : ', ref($obj), "\n\n";
my $obj2 = Test2-new;
print 'TEST2 PACKAGE OBJECT : ', ref($obj2), "\n\n";
## FYI
print '- ' x 10, 'TEST', ' -' x 10, "\n";
print map { "$_ - $Test::{$_}\n" } keys %Test:: ;
print '- ' x 10, 'TEST2', ' -' x 10, "\n";
print map { "$_ - $Test2::{$_}\n" } keys %Test:: ;
BEGIN {
package Test;
sub new {
my $class =shift;
print "SETTING OBJECT TO CLASS : $class\n";
bless my $obj = {}, $class;
}
}
---
NewPackage will then contain all things in TestPackage
Then you can redefined everything in TestPackage without affecting
anything in NewPackage.
Actually it will, if you were to delete NewPackage, TestPackage would not
contain anything. Modifying 'thingys' in TestPackage would modify
NewPackage.
Actually I investigated this a little more and discovered some
strange things...
If you check out the results, copying the package at the package
level cause scalars to be redefined and subroutines to created as
references. Where as copying the the package at the glob level
caused the the subroutines to be redefined and the scalars to be
references...
I wonder if this is a problem with perl?
Robert Landrum
--- results ---
# perl n.pl 1
NewPackage::x was defined
NewPackage::june was defined
$NewPackage::x was set to 100
$Test::x now contains 100
Now Deleting Test package
Test::x was deleted from the STASH
Test::june was deleted from the STASH
$NewPackage::x was set to 100
$Test::x now contains 100
Now Listing NewPackage
NewPackage::x
NewPackage::june
Now Listing Test
# perl n.pl
NewPackage:: was defined as *{Test::}
$NewPackage::x was set to 100
$Test::x now contains 1
Now Deleting Test package
Test::x was deleted from the STASH
Test::june was deleted from the STASH
$NewPackage::x was set to 100
$Test::x now contains 1
Now Listing NewPackage
Now Listing Test
--- Contents of n.pl ---
#!/usr/bin/perl
package Test;
our $x = 1;
sub june {
}
package main;
if($ARGV[0]) {
for my $name (keys %{Test::}) {
*{"NewPackage::".$name} = *{"Test::".$name};
print "NewPackage::".$name." was defined\n";
}
print "\n";
} else {
*{NewPackage::} = *{Test::};
print "NewPackage:: was defined as \*{Test::}\n";
print "\n";
}
$NewPackage::x = 100;
print "\$NewPackage::x was set to $NewPackage::x\n";
print "\$Test::x now contains $Test::x\n";
print "\n";
print "Now Deleting Test package\n";
for my $name (keys %{Test::}) {
delete $Test::{$name};
print "Test::".$name." was deleted from the STASH\n";
}
print "\n";
print "\$NewPackage::x was set to $NewPackage::x\n";
print "\$Test::x now contains $Test::x\n";
print "\n";
print "Now Listing NewPackage\n";
for my $name (keys %{NewPackage::}) {
print "NewPackage::".$name."\n";
}
print "\n";
print "Now Listing Test\n";
for my $name (keys %{Test::}) {
print "Test::".$name."\n";
}
print "\n";
Unable to build Apache::Scoreboard 0.10 with 5.6.0/1.3.17/1.25/RH 6.2
I am encountering the following problem when attempting to install Apache::Scoreboard 0.10 on a fresh Red Hat 6.2 install (2.2.14-5.0 kernel) with Perl 5.6.0, Apache 1.3.17, and mod_perl 1.25 (all installed from source, not the RH RPMs): /usr/local/src/Apache-Scoreboard-0.10 109 perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for Apache::DummyScoreboard Writing Makefile for Apache::Scoreboard /usr/local/src/Apache-Scoreboard-0.10 114 make make[1]: Entering directory `/usr/local/src/Apache-Scoreboard-0.10/Dummy' cc -c -I../ -I/usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include -I/usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/modules/perl -I/usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/include -I/usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/regex -I/usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/os/unix -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\"0.04\" -DXS_VERSION=\"0.04\" -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE DummyScoreboard.c In file included from DummyScoreboard.xs:2: /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/include/scoreboard.h:151: field `start_time' has incomplete type /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/Apache/include/include/scoreboard.h:152: field `stop_time' has incomplete type make[1]: *** [DummyScoreboard.o] Error 1 make[1]: Leaving directory `/usr/local/src/Apache-Scoreboard-0.10/Dummy' make: *** [subdirs] Error 2 /usr/local/src/Apache-Scoreboard-0.10 115 I have seen posts about similar types of problems folks have experienced in the past, but have verified the above version numbers of related installs, and am under the impression this should work. Can anyone help shed some light on this?
[RFC] Apache::BlockSymLinks 0.1
Hi Folks, I've got a situation that needed a solution. Say I have a directory in my htdocs that contains: frames.html- a document index.html - frames.html - a symbolic link hacker.txt - /etc/passwd - another symbolic link I'd like to allow the index.html link to work, but deny the hacker.txt one. Disallowing the FollowSymLinks option kills both links. SymLinksIfOwnerMatch option helps, but I have numerous authors on my server so I cannot guarantee the same owner on each file. Tried something like this: Directory /usr/local/etc/httpd/htdocs Order allow,deny Allow from all /Directory Directory / Order deny, allow Deny from all /Directory but a request for htdocs/hacker.txt doesn't seem to realize the file is really in /etc, so it sends the file out. (Perhaps I missed something here?) The solution I came up with is to write an access handler to evaluate symlinked filepaths and test the absolute path against a set of rules. I called the module Apache::BlockSymLinks since it is based on Apache::BlockAgent. The code can be downloaded from: http://mosa.unity.ncsu.edu/brabec/dist/Apache-BlockSymLinks-0.1.tar.gz and the manpage is online at: http://mosa.unity.ncsu.edu/brabec/dist/BlockSymLinks.html I'm considering adding this module to CPAN and/or the APML, so I'm looking for comments. Specifically, is this useful to others? have I reinvented the wheel? any suggestions for additions or modifications? Thanks, Charles -- Dr. Charles J. Brabec | He wants me to be clever. Worse, he wants me to be Web Systems Programmer | seen to be clever by everyone here. -- Miles [EMAIL PROTECTED]| Vorkosigan (L.M. Bujold) PH 919.513.0171|
RE: [RFC] Apache::BlockSymLinks 0.1
-Original Message- From: Charles John Brabec [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 12:48 PM To: [EMAIL PROTECTED] Subject: [RFC] Apache::BlockSymLinks 0.1 [snip] I called the module Apache::BlockSymLinks since it is based on Apache::BlockAgent. The code can be downloaded from: http://mosa.unity.ncsu.edu/brabec/dist/Apache-BlockSymLinks-0.1.tar.gz and the manpage is online at: http://mosa.unity.ncsu.edu/brabec/dist/BlockSymLinks.html I'm considering adding this module to CPAN and/or the APML, so I'm looking for comments. Specifically, is this useful to others? have I reinvented the wheel? any suggestions for additions or modifications? I'm not sure that I'll ever have a need for it, but it's a neat idea. you may want to look into Apache::ModuleConfig to see how you can create directives without the need for a separate config file. for instance: SymLinkRule Deny .* it's pretty easy and probably a bit cleaner in this case (since I suspect that you moved to a config file since PerlSetVar just didn't fit the bill for the syntax you wanted). just see chapter 8 of the Eagle book for Apache modules, once you have the (rather loose) approval of the list, you can submit to upload to PAUSE without officially registering your module... just announce it here and (separatly) submit a patch to the module list (apache-modlist.html from cvs) --Geoff Thanks, Charles -- Dr. Charles J. Brabec | He wants me to be clever. Worse, he wants me to be Web Systems Programmer | seen to be clever by everyone here. -- Miles [EMAIL PROTECTED]| Vorkosigan (L.M. Bujold) PH 919.513.0171|
ServerRoot/Block Directive question...
Hi all, I have an Apache::GateKeeper that checks to see if the user has logged in and been served a cookie... if not they are redirected to index.html(to login). I want all comers to ServerRoot/cgi-bin or ServerRoot/perl to have to go thru the GateKeeper handler, except those trying to get to login.cgi which lives in ServerRoot/perl. I was trying to use the perl.conf Block Directives below, but am not getting the negated Files !~ line to work right. I snooped around on the mail archives but can't find anything about negated regex matching. PerlRequire conf/startup.pl PerlFreshRestartOn PerlSetEnv MOD_PERL_TRACE all #Directory Handlers #-- Directory /perl AllowOverride None Options +ExecCGI SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On /Directory Directory ~ (cgi-bin|perl) Files !~ "login.cgi" PerlAccessHandler Apache::GateKeeper ErrorDocument 403 /index.html /Files /Directory Thanks, Joe Crotty
RE: [RFC] Apache::BlockSymLinks 0.1
Geoff, et al: I've toyed with ModuleConfig, and it is really cool, but I was under the impression that people stayed away from using it since it appears to require a recompile of mod_perl for every module that inserts a new directive into the list. That's why I assumed the use of PerlSetVar was much more popular than ModuleConfig. Regards, Christian On Fri, 2 Feb 2001, Geoffrey Young wrote: you may want to look into Apache::ModuleConfig to see how you can create directives without the need for a separate config file. for instance: SymLinkRule Deny .* it's pretty easy and probably a bit cleaner in this case (since I suspect that you moved to a config file since PerlSetVar just didn't fit the bill for the syntax you wanted). just see chapter 8 of the Eagle book
Re: Apache::ASP installation problem
"Wang, Pin-Chieh" wrote: Hi, I am using Apache 1.3.14 with mod_perl-1.24_01 on Solaris system The Apache/Mod_perl part of build is working fine. But when I installed Apache-ASP-2.07, during the make test part I got Undefied Routine Devel/Symdump error therefore the make test failed. So, I download and try to install Devel-Symdump-2.00, the make test failed with error code 29 on Command failed for target 'test-dynamic' Your other mail said that you got Devel-Symdump-2.01 working. Just closing this thread. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Socket/PIPE/Stream to long running process
So, in my mod_perl app, I run thru each request, then blast a UDP packet to
a process on the local machine that collects statistics on my traffic:
sub send_packet {
my $r = shift;
my $packet = shift;
$r-warn("send_packet: No packet, not transmitting") if $debug
!$packet;
return unless $packet;
$r-warn("Contents:\n$packethr") if $debug;
$r-warn("send_packet: creating socket") if $debug;
my $socket = new IO::Socket::INET (
PeerAddr =
$r-dir_config('CountServer'),
Proto= 'udp',
)
or die "CountServer unable to create socket: $@\n";
$r-warn("send_packet: Sending to ", $r-dir_config('CountServer')) if
$debug;
# OK we have the correct buffer, lets send it out...
unless ($socket-send($packet) == length $packet) {
$r-warn( "send error on " . $socket-peerhost . ": $!" );
return SERVER_ERROR;
#redir($r-dir_config('ErrorURL'));
}
$r-warn( "send_packet: send succesful") if $debug;
}
My question is, should I be creating this socket for every request? OR
would it be more "correct" to create it once on process startup and stash it
in $r-pnotes or something?
And if I did that, would it work w/ TCP? Or unix pipes/sockets (which I
*don't* understand) (btw the box is linux)? In testing, I'd prefer not to
use TCP because it blocks if the count server is hung or down, vs UDP, where
I just lose a couple of packets.
TIA!
L8r,
Rob
Re: ServerRoot/Block Directive question...
There is no negation of an entire regex in apache's configuration. You have to do something like this: DirectoryMatch "^(cgi-bin|perl)$" PerlAccessHandler Apache::GateKeeper ErrorDocument 403 /index.html Files "login.cgi" PerlAccessHandler Apache::OK /Files /DirectoryMatch Regards, Christian On Fri, 2 Feb 2001, Joseph Crotty wrote: Hi all, I have an Apache::GateKeeper that checks to see if the user has logged in and been served a cookie... if not they are redirected to index.html(to login). I want all comers to ServerRoot/cgi-bin or ServerRoot/perl to have to go thru the GateKeeper handler, except those trying to get to login.cgi which lives in ServerRoot/perl. I was trying to use the perl.conf Block Directives below, but am not getting the negated Files !~ line to work right. I snooped around on the mail archives but can't find anything about negated regex matching. PerlRequire conf/startup.pl PerlFreshRestartOn PerlSetEnv MOD_PERL_TRACE all #Directory Handlers #-- Directory /perl AllowOverride None Options +ExecCGI SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On /Directory Directory ~ (cgi-bin|perl) Files !~ "login.cgi" PerlAccessHandler Apache::GateKeeper ErrorDocument 403 /index.html /Files /Directory Thanks, Joe Crotty
Re: [RFC] Apache::BlockSymLinks 0.1
Christian, Geoff, et al, I was not aware of the Apache::ModuleConfig setup, thanks for the pointer. According to chapter 8, p388, the setup requires configuring the Makefile.PL so it will create an .xs file and compile it as part of the make process. The module must be loaded into Apache via a PerlModule statement, but it does not require a rebuild of Apache or mod_perl. Is that about right? In my case, I would gain the ability to list the directives explicitly inside the Dierctory container (which I like). I would lose the ability to change the config file without a restart of the server. (Inconvenient, but not a show-stopper) Thanks again for the info. Charles I've toyed with ModuleConfig, and it is really cool, but I was under the impression that people stayed away from using it since it appears to require a recompile of mod_perl for every module that inserts a new directive into the list. That's why I assumed the use of PerlSetVar was much more popular than ModuleConfig. Regards, Christian On Fri, 2 Feb 2001, Geoffrey Young wrote: you may want to look into Apache::ModuleConfig to see how you can create directives without the need for a separate config file. for instance: SymLinkRule Deny .* it's pretty easy and probably a bit cleaner in this case (since I suspect that you moved to a config file since PerlSetVar just didn't fit the bill for the syntax you wanted). just see chapter 8 of the Eagle book -- Dr. Charles J. Brabec | I know now that there's one thing you've all Web Systems Programmer | overlooked: intelligence and education that hasn't [EMAIL PROTECTED]| been tempered by human affection isn't worth a damn. - PH 919.513.0171| - Daniel Keyes, 'Flowers for Algernon'
RE: [RFC] Apache::BlockSymLinks 0.1
-Original Message- From: Christian Gilmore [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 2:00 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: [RFC] Apache::BlockSymLinks 0.1 Geoff, et al: I've toyed with ModuleConfig, and it is really cool, but I was under the impression that people stayed away from using it since it appears to require a recompile of mod_perl for every module that inserts a new directive into the list. That's why I assumed the use of PerlSetVar was much more popular than ModuleConfig. I think PerlSetVar is more popular because it's easier to implement and doesn't require much effort. ModuleConfig.pm is a bit more complex, but it is still just straight perl and doesn't require XS to implement. It depends on your needs, though - I wouldn't use it when you only need a few config directives but I might prefer it to a file-based config like BlockSymLinks uses. as far as the recompiling of mod_perl goes, that doesn't make sense to me. Apache::Dispatch uses ModuleConfig for all it's parameters and you should be good to go with just the typical make stuff. --Geoff Regards, Christian On Fri, 2 Feb 2001, Geoffrey Young wrote: you may want to look into Apache::ModuleConfig to see how you can create directives without the need for a separate config file. for instance: SymLinkRule Deny .* it's pretty easy and probably a bit cleaner in this case (since I suspect that you moved to a config file since PerlSetVar just didn't fit the bill for the syntax you wanted). just see chapter 8 of the Eagle book
RE: [RFC] Apache::BlockSymLinks 0.1
-Original Message- From: Charles John Brabec [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 2:36 PM To: Christian Gilmore Cc: Geoffrey Young; [EMAIL PROTECTED] Subject: Re: [RFC] Apache::BlockSymLinks 0.1 Christian, Geoff, et al, I was not aware of the Apache::ModuleConfig setup, thanks for the pointer. According to chapter 8, p388, the setup requires configuring the Makefile.PL so it will create an .xs file and compile it as part of the make process. The module must be loaded into Apache via a PerlModule statement, but it does not require a rebuild of Apache or mod_perl. Is that about right? yup. the only thing you have to do is follow the example for the Makefile.PL and then code the appropriate stuff in your .pm to handle how you want to store the data your new directive gives you. See Apache::Dispatch or AxKit working examples (those are the only two I can't think of others offhand that use it) In my case, I would gain the ability to list the directives explicitly inside the Dierctory container (which I like). I would lose the ability to change the config file without a restart of the server. (Inconvenient, but not a show-stopper) yes - I haven't checked into the implications of a restart + ModuleConfig directives, though (whether mod_perl can pick up on the changes). I'll have to look into it. --Geoff Thanks again for the info. Charles I've toyed with ModuleConfig, and it is really cool, but I was under the impression that people stayed away from using it since it appears to require a recompile of mod_perl for every module that inserts a new directive into the list. That's why I assumed the use of PerlSetVar was much more popular than ModuleConfig. Regards, Christian On Fri, 2 Feb 2001, Geoffrey Young wrote: you may want to look into Apache::ModuleConfig to see how you can create directives without the need for a separate config file. for instance: SymLinkRule Deny .* it's pretty easy and probably a bit cleaner in this case (since I suspect that you moved to a config file since PerlSetVar just didn't fit the bill for the syntax you wanted). just see chapter 8 of the Eagle book -- Dr. Charles J. Brabec | I know now that there's one thing you've all Web Systems Programmer | overlooked: intelligence and education that hasn't [EMAIL PROTECTED]| been tempered by human affection isn't worth a damn. - PH 919.513.0171| - Daniel Keyes, 'Flowers for Algernon'
Error using mod_per 1.25 with Apache 1.3.17 and perl 5.6.0
Can anyone explain why this happens?? Server is not starting !? Subroutine main::pid redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 103. Subroutine main::access redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 104. Subroutine Outside::code redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 108. Subroutine PerlTransHandler::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 114. Subroutine MyClass::method redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 121. Subroutine BaseClass::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 127. Subroutine My::child_init redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 145. Subroutine My::child_exit redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 155. Subroutine My::restart redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 159. Subroutine Apache::AuthenTest::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 167. Subroutine My::DirIndex::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 189. Subroutine My::ProxyTest::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 207. Subroutine handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 241. Subroutine new redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 263. Subroutine DESTROY redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 265. [notice] Destruction-DESTROY called for $global_object Subroutine handler redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 6. Subroutine one redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 14. Subroutine two redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 25. Subroutine three redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 31. Subroutine four redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 37. [notice] Destruction-DESTROY called for $global_object [Thu Feb 1 20:24:46 2001] [error] Incorrect permissions on key directory "/usr/local/frontpage/version5.0/apache-fp" in FrontPageCheckup(). Until this problem is fixed, the FrontPage security patch is disabled and the FrontPage extensions may not work correctly. [Thu Feb 1 20:24:46 2001] [warn] [notice] child_init for process 11410, report any problems to [no address given] Server is not starting !? Subroutine main::pid redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 103. Subroutine main::access redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 104. Subroutine Outside::code redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 108. Subroutine PerlTransHandler::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 114. Subroutine MyClass::method redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 121. Subroutine BaseClass::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 127. Subroutine My::child_init redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 145. Subroutine My::child_exit redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 155. Subroutine My::restart redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 159. Subroutine Apache::AuthenTest::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 167. Subroutine My::DirIndex::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 189. Subroutine My::ProxyTest::handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 207. Subroutine handler redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 241. Subroutine new redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 263. Subroutine DESTROY redefined at /usr/source/mod_perl-1.25/t//docs/startup.pl line 265. [notice] Destruction-DESTROY called for $global_object Subroutine handler redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 6. Subroutine one redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 14. Subroutine two redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 25. Subroutine three redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 31. Subroutine four redefined at /usr/source/mod_perl-1.25/t//docs/stacked.pl line 37. [Fri Feb 2 16:24:06 2001] [warn] pid file /usr/source/mod_perl-1.25/t/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [notice] Destruction-DESTROY called for $global_object [Fri Feb 2 16:24:07 2001] [error] Incorrect permissions on key directory "/usr/local/frontpage/version5.0/apache-fp" in FrontPageCheckup(). Until this problem is fixed, the FrontPage security patch is disabled and the FrontPage extensions may not work correctly. [Fri Feb 2 16:24:07 2001] [warn] [notice] child_init for process 3837, report any problems to [no address given] BTW SCREW fp.
INIT Blocks under mod_perl
Does anybody know if INIT blocks work under mod_perl? I was trying to get
Geography::States to work under mod_perl and it doesn't seem to run the
code in the INIT block. When I removed "INIT {" and the corresponding
"}" line from the Geography/States.pm file, the code ran fine.
I'm running mod_perl 1.24_01, Apache 1.3.14.
Thanks, TJ
_
T.J. Mather http://tjmather.com
http://cpan2.org/ New CPAN Search Engine
http://www.anidea.com/ Digital Asset Management
http://www.theinnkeeper.com/Bed and Breakfast Directory
Re: This list... formatted headerS?
So based on some of the recent comments, am I correct in thinking this document should go up pretty soon now with an official URL on the Apache Perl site? I don't like FTP url's cuz there's quite a few firewalls that just allow people to browse but not FTP://... It seemed like it was refined enough that people could refer to the link when they tell people not to post off topic etc... already. So any comments that come in could be incorporated later (because they probably won't result in earth shattering changes at this stage). At 12:04 AM 1/31/01 +, G.W. Haywood wrote: Hi there, On Tue, 30 Jan 2001, wells wrote: Why doesn't this list use formatted headers, e.g. Subject: [mod-perl] Would be great for filtering.. Argh. Three months ago I asked for comments on this document. I got precisely one. Thanks again, Gunther! -- From [EMAIL PROTECTED] Sun Nov 5 15:32:06 2000 Date: Sun, 5 Nov 2000 15:32:05 + (GMT) From: "G.W. Haywood" [EMAIL PROTECTED] To: Ask Bjoern Hansen [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: [ADMIN] Keep those @$%#$ quotes down (was: dynamic vs. mostly static data) In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: Hi all, On Sun, 5 Nov 2000, Ask Bjoern Hansen wrote: Sending a 3.5KB message to write two misspelled lines are a %@$%$ waste. Those 3.5KB goes to ~1500 people. Your outburst (with which I have to agree, although maybe we might talk about banner ads later:) prompted me to publish a document that Stas and I have been working on, if sporadically, for quite a while. It's available by anonymous ftp: ftp.jubileegroup.co.uk/pub/mod_perl/admin/admin.txt -- 73, Ged. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: Using modperl as an 'adaptor' front end to an app server.
Once upon a time Dave Rolsky shaped the electrons to say... On Thu, 1 Feb 2001, Daniel Sully wrote: server. It handles failover from dead app instances, however not very well, and is a big pile of C code. It also has problems in that because Apache is not multithreaded, one child copy of that adaptor that has marked an app instance as dead can't let another child know about that dead instance. You could use an IPC or DBM file (assuming you have 1 apache machine) to communicate this info. With multiple webservers, you'd need a database or NFS or something. That would be a no. Socket communication only. Shared filesystems in production are bad, mmkay. -D -- yip yip yip yip yip yap yap yip yip yip BANG NO TERRIER
Apache::SizeLimit MAX UNSHARED patch
Hey,
Per Perrin Harkin's advice, and my client's consent, I hacked
up Apache::SizeLimit to support MAX_PROCESS_UNSHARED_SIZE config,
where instead of limiting by the apparent process size, one limits
by the amount of unshared memory being used. Unshared memory is the
effective process size, in terms of how much of your machine's RAM
its eating. It rewards you for pre-loading modules and pre-compiling
scripts in your parent httpd.
The patch is below, and only supports this config on linux.
My development was on a linux 2.2 kernel, a relies on the format
in /proc/self/statm staying the same.
As Perrin's tells it in a previous thread, this is apparently
a better method of limiting your processes, than
Apache::GTopLimit's MIN_PROCESS_SHARED_SIZE, and further
does not require installation of libgtop.
Please mail me for the full file, if this diff is too unwieldy.
--Josh
--- SizeLimit.pm~ Fri Feb 2 11:36:43 2001
+++ SizeLimit.pmFri Feb 2 13:52:39 2001
@@ -14,6 +14,9 @@
use Apache::SizeLimit;
$Apache::SizeLimit::MAX_PROCESS_SIZE = 1; # in KB, so this is 10MB
+# in KB, so this is 10MB, only supported under linux currently
+$Apache::SizeLimit::MAX_PROCESS_UNSHARED_SIZE = 1;
+
# in your httpd.conf:
PerlFixupHandler Apache::SizeLimit
# you can set this up as any Perl*Handler that handles part of the
@@ -26,6 +29,7 @@
# in your CGI:
use Apache::SizeLimit;
Apache::SizeLimit::setmax(1); # Max Process Size in KB
+Apache::SizeLimit::setmax_unshared(1); # Max Unshared RAM Size in KB
Since checking the process size can take a few system calls on some
platforms (e.g. linux), you may want to only check the process size every
@@ -83,6 +87,9 @@
(with the Csetmax function), and see if the CHECK_EVERY_N_REQUESTS
option is of benefit.
+Currently, linux is the only platform that supports the
+MAX_PROCESS_UNSHARED_SIZE and setmax_unshared() settings.
+
=item solaris 2.6
For solaris we simply retrieve the size of /proc/self/as, which
@@ -120,12 +127,14 @@
use Apache::Constants qw(:common);
use Config;
use strict;
-use vars qw($VERSION $HOW_BIG_IS_IT $MAX_PROCESS_SIZE
- $REQUEST_COUNT $CHECK_EVERY_N_REQUESTS);
+use vars qw($VERSION $HOW_BIG_IS_IT $HOW_UNSHARED_IS_IT
+ $MAX_PROCESS_SIZE $MAX_PROCESS_UNSHARED_SIZE
+ $REQUEST_COUNT $CHECK_EVERY_N_REQUESTS $CHECK_TOTAL);
-$VERSION = '0.03';
+$VERSION = '0.05';
$CHECK_EVERY_N_REQUESTS = 1;
$REQUEST_COUNT = 1;
+$CHECK_TOTAL = 0;
BEGIN {
# decide at compile time how to check for a process' memory size.
@@ -134,6 +143,7 @@
$HOW_BIG_IS_IT = \solaris_2_6_size_check;
} elsif ($Config{'osname'} eq 'linux') {
$HOW_BIG_IS_IT = \linux_size_check;
+ $HOW_UNSHARED_IS_IT = \linux_unshared_size_check;
} elsif ($Config{'osname'} =~ /(bsd|aix)/i) {
# will getrusage work on all BSDs? I should hope so.
if (eval("require BSD::Resource;")) {
@@ -159,6 +169,24 @@
return($size);
}
+sub linux_unshared_size_check {
+my $unshared_size = 0;
+local(*FH);
+if (open(FH, "/proc/self/statm")) {
+ my $data = FH;
+ close(FH);
+ my($size, $resident, $shared) = split(/\s+/, $data);
+ if($resident $shared) {
+ $unshared_size = 4 * ($resident - $shared); # 4KB pages listed
+ } else {
+ error_log("Fatal Error: /proc/self/statm not right format, got: $data");
+ }
+} else {
+ error_log("Fatal Error: couldn't access /proc/self/statm: $!");
+}
+return($unshared_size);
+}
+
sub solaris_2_6_size_check {
my $size = -s "/proc/self/as" or
error_log("Fatal Error: /proc/self/as doesn't exist or is empty");
@@ -171,6 +199,7 @@
}
sub exit_if_too_big {
+$CHECK_TOTAL++;
return if ($REQUEST_COUNT++ $CHECK_EVERY_N_REQUESTS);
$REQUEST_COUNT = 1;
if (defined($MAX_PROCESS_SIZE)) {
@@ -184,8 +213,25 @@
error_log("main process too big, SIZE=$size KB");
}
}
+} elsif (defined($MAX_PROCESS_UNSHARED_SIZE)) {
+ if($HOW_UNSHARED_IS_IT) {
+ my $size = $HOW_UNSHARED_IS_IT();
+ if($size $MAX_PROCESS_UNSHARED_SIZE) {
+ if(getppid 1) { # this is a child httpd
+ error_log("httpd process too unshared, exiting at UNSHARED
+SIZE=$size KB, after $CHECK_TOTAL checks");
+ Apache::exit(-2);
+ } else {
+ # don't do anything for main httpd
+ }
+ } else {
+ # don't do anything
+ }
+ } else {
+ error_log("no MAX_PROCESS_UNSHARED_SIZE handler for this platform $^O, ".
+ "currently only linux supported");
+ }
} else {
- error_log("you didn't set \$Apache::SizeLimit::MAX_PROCESS_SIZE");
+ error_log("you didn't set \$Apache::SizeLimit::MAX_PROCESS_SIZE or
Doh; StatINC can't find files?
Hi folks, Maybe I'm just rusty after 8 months off, but my StatINC can't find files that exist on the system: wm ~tail ~wm/wm/logs/errorlog Apache::StatINC: Can't locate /home/wm/wm/perl/WM/Class.pm wm ~perl -e '$file="/home/wm/wm/perl/WM/Class.pm"; $mtime = (stat $file)[9]; warn $mtime;' 963258607 at -e line 1. I thought it might be perms, but: wm ~ls -la /home/wm/wm/perl/WM/Class.pm -rwxrwxr-x1 wm wm 10357 Jul 20 2000 /home/wm/wm/perl/WM/Class.pm And the same thing happens with Apache::Reload ... I'm sure I'm missing something obvious; any clues? Thanks -nick
modperl + FrontPage Server Extensions
Hi Everybody I've a Linux box already running Apache/1.3.14 compiled with mod_perl-1.24_01 running Apache-ASP-2.03. Well the question is if Installing FrontPage Server Extensions will conflict?. Thanks in advance Regards -Jose [EMAIL PROTECTED] www.datacourse.com
Re: Using modperl as an 'adaptor' front end to an app server.
On Fri, 2 Feb 2001, Daniel Sully wrote: You could use an IPC or DBM file (assuming you have 1 apache machine) to communicate this info. With multiple webservers, you'd need a database or NFS or something. That would be a no. Socket communication only. Shared filesystems in production are bad, mmkay. I'm not sure which you're referring to, my suggestion that you use a DBM file (with locking, of course) on 1 machine or NFS. I have no experience with NFS myself but I've heard of other using it for such things (or trying to, at least). I would think a database would end up being the simplest way to do this sort of information passing. -dave /*== www.urth.org We await the New Sun ==*/
Re: Using modperl as an 'adaptor' front end to an app server.
Once upon a time Dave Rolsky shaped the electrons to say... That would be a no. Socket communication only. Shared filesystems in production are bad, mmkay. I'm not sure which you're referring to, my suggestion that you use a DBM file (with locking, of course) on 1 machine or NFS. I have no experience with NFS myself but I've heard of other using it for such things (or trying to, at least). I would think a database would end up being the simplest way to do this sort of information passing. There is too much overhead for using a locking a database across a shared filesystem with potential latency problems and blocking/deadlock potential. A direct socket connection, or even tossing a multicast packet out onto the wire is the best for inter-machine communication, where there may be N machines that are available to answer that request. -D -- fall down seven times, get up eight.
