RFC: Apache::FileMan 0.06
I have updated Apache::FileMan.pm to pre-release version 0.06. FileMan provides a file manager for a web sites through a web browser. It is an extensive rewrite of the Apache::AutoIndex.pm module (written by Philippe M. Chiasson), which in turn was a remake of the autoindex Apache C module. FileMan can provide the same functionality as AutoIndex.pm, so it can be used to both to navigate and manage a web site. The source is available at: http://www.xorgate.com/FileMan A demo is also available. I need help from others to fill in the FileMan.dic file for Apache::Language phrases and nomenclature. I have included all the English entries, but have not a clue what to put in for the other languages.-) Hopefully, I will be able to release this to CPAN in the near future. Please provide any suggestions, feedback, or what ever. Thanks.
are there any missing modules?
Well, I've finally have cracked this tedious task down. I've pretty much done with the modules chapter for the book (of course I didn't document all of them, it'll require a separate book if I did. but quite many are documented). So please take a look at this list and tell me whether I've missed something and you want it to be on the list. Note that I've re-grouped the modules differently from the original Apache::* list. Thanks. Development Stage Modules Apache::Reload Apache::PerlVINC - Allows Module Versioning in Location blocks and Virtual Hosts Apache::DProf - Hook Devel::DProf into mod_perl Apache::SmallProf - Hook Devel::SmallProf into mod_perl Apache::FakeRequest - fake request object for debugging Apache::test - Facilitates testing of Apache::* modules Debug Stage Modules Apache::DB - Hooks for the interactive Perl debugger Apache::Debug - Utilities for debugging embedded perl code Apache::DebugInfo - Send Debug Info to Client Apache::Leak - Module for tracking memory leaks in mod_perl code Apache::Peek - A data debugging tool for the XS programmer Apache::Symbol - avoid a mandatory 'subroutine redefined' warning Apache::Symdump - Symbol table snapshots Monitoring and Controlling Modules Apache::Watchdog::RunAway - Hanging Processes Monitor and Terminator Apache::VMonitor Apache::SizeLimit - Limit Apache httpd Processes Apache::GTopLimit - Limit Apache httpd Processes Apache::TimedRedirect - Redirect URLs for a given time period Apache::Resource - Limit resources used by httpd children Apache::Status - Embedded interpreter status information Server Configuration Apache::ModuleConfig - Interface to configuration API Apache::PerlSections - Utilities for work with sections Apache::httpd_conf - Generate an httpd.conf file Apache::src - Methods for locating and parsing bits of Apache source code Authentication Phase Modules AuthenCache Cache authentication credentials AuthCookie Authentication and Authorization via cookies AuthenDBI Authenticate via Perl's DBI AuthenIMAP Authentication via an IMAP server AuthenPasswdSrv External authentication server AuthenPasswdAuthenticate against /etc/passwd AuthLDAPLDAP authentication module AuthPerLDAP LDAP authentication module (PerLDAP) AuthenNIS NIS authentication AuthNISPlus NIS Plus authentication/authorization AuthenSmb Authenticate against NT server AuthenURL Authenticate via another URL DBILoginAuthenticate to backend database PHLogin Authenticate via a PH database Authorization Phase Modules AuthCookie Authen + Authz via cookies AuthzDBIGroup authorization via Perl's DBI AuthzNISNIS authorization AuthzPasswd Authorize against /etc/passwd Access Phase Modules AccessLimitNum Limit user access by number of requests IPThrottle Limit bandwith consumption by IP RobotLimit Limit access of robots PerlTransHandlers Apache::AddHostPath - Adds some or all of the hostname and port to the URI Apache::ProxyPass - implement ProxyPass in perl Apache::ProxyPassThru - Skeleton for vanilla proxy Apache::Throttle - a speed based content negotiation Apache::TransLDAP - Trans Handler Example Fixup Handlers Apache::RefererBlock - block request based upon "Referer" header Apache::Usertrack - Emulate the mod_usertrack Apache module Generic Content Generating Phase Modules Apache::Registry and Apache::PerlRun Apache::RegistryNG - Apache::Registry New Generation Apache::RegistryBB - Apache::Registry Bare Bones Apache::Session - Maintain Session State Across HTTP Requests Apache::Request (libapreq) - Generic Apache Request Library Apache::Dispatch - call PerlHandlers with the ease of Registry scripts Application Specific Content Generating Phase Modules Apache::AutoIndex - Perl replacement for mod_autoindex and mod_dir Apache modules Apache::WAP::AutoIndex - WAP demostration module Apache::WAP::MailPeek - Demonstrate the Use of Delivery of WML Apache::Archive - Expose archive files through the Apache web server. Apache::Gateway - Implement gateway Apache::NNTPGateway - a NNTP interface for mod_perl enabled Apache web server. Apache::PrettyPerl - Syntax highlighting for Perl files Apache::PrettyText - Re-format .txt files for client display Apache::RandomLocation - Random files display Apache::Stage - Manage A Staging Directory Apache::Roaming - A mod_perl handler for Roaming Profiles Apache::Backhand - write mod_backhand functions in Perl DataBase Modules Apache::DBI - Initiate a Persistent Database Connection Apache::OWA - Oracle's PL/SQL Web Toolkit for A
Re: apachecon: BOF?
On Wed, 14 Feb 2001, Gunther Birznieks wrote: > I wouldn't mind a mod_perl beer-BOF like the one we had at the last night > of ApacheCon Europe That's the unofficial one :) But seriously, if there is an interest, you should tell us. Otherwise we will just hang out in some pub. Well, we will do it anyway :) > At 04:51 PM 2/12/2001 +0800, Stas Bekman wrote: > >Do we want to have a mod_perl BOF at ApacheCon? or related? I've just > >logged into apachecon system to see this option to request a BOF. > > > >what about gizmos? mod_perl underwear/socks anybody? Laser link (Geoff?) > >or some new guys? > > > >_ > >Stas Bekman JAm_pH -- Just Another mod_perl Hacker > >http://stason.org/ mod_perl Guide http://perl.apache.org/guide > >mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ > >http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ > > __ > Gunther Birznieks ([EMAIL PROTECTED]) > eXtropia - The Web Technology Company > http://www.extropia.com/ > _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: apachecon: BOF?
On Wed, 14 Feb 2001, Gunther Birznieks wrote: > I wouldn't mind a mod_perl beer-BOF like the one we had at the last night > of ApacheCon Europe I'll go, but I won't drink any beer. -dave /*== www.urth.org We await the New Sun ==*/
Re: apachecon: BOF?
I wouldn't mind a mod_perl beer-BOF like the one we had at the last night of ApacheCon Europe At 04:51 PM 2/12/2001 +0800, Stas Bekman wrote: >Do we want to have a mod_perl BOF at ApacheCon? or related? I've just >logged into apachecon system to see this option to request a BOF. > >what about gizmos? mod_perl underwear/socks anybody? Laser link (Geoff?) >or some new guys? > >_ >Stas Bekman JAm_pH -- Just Another mod_perl Hacker >http://stason.org/ mod_perl Guide http://perl.apache.org/guide >mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ >http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
RE: compiling mod_perl without root...
On Tue, 13 Feb 2001, Joseph Crotty wrote: > Ged, > > Thanks for the reply. The heart of the problem is we need to compile > apache/mod_perl from source(i.e. apache_1.3.14.tar.gz and > mod_perl1-1.25.tar.gz) which lives in cvs. As Ged has mentioned, you need to read the guide: http://perl.apache.org/guide/install.html#Installation_Without_Superuser_P _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[ANNOUNCE] Cache::Cache 0.01
Hello: Perl Cache is the successor to the popular File::Cache and IPC::Cache perl libraries. This project unifies those modules under the generic Cache::Cache interface and implements Cache::FileCache, Cache::MemoryCache, and Cache::SharedMemoryCache. The project is being hosted on SourceForge at: http://sourceforge.net/projects/perl-cache/ I have released the first version of the unified Cache code as version 0.01, and it can be downloaded here: http://download.sourceforge.net/perl-cache/Cache-Cache-0.01.tar.gz I have not implemented the full functionality of File::Cache (e.g., dynamic cache sizing) quite yet. I am in the process of porting that code and it will be included in the next release as a new module. Comments and critique always welcome! Cheers, -DeWitt
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Well, if I call the "check for things to do" URI every minute, then I'll > be just fine. Many times, I'll just check and find nothing to do Huh? Why would you call it if there's nothing to do? Are you thinking you'll write a cron-ish task/timing spec for your Perl app and just use the cron triggers as a constant clock? - Perrin
Re: mod_perl for Win32 + ActiveState Perl 5.6 (build 616) + Apache 1.3.12
Hi, Yes - and you can even install it using ppm. Go to: http://perl.apache.org/distributions.html and follow instructions regarding ppm install. I used this method to successfully (and easily) install mod_perl1.24_02-dev on Apache 1.3.12 (Windows 98, AS 613). I can't exactly recall what I specified for 'xxx' and 'yyy' - probably '1.24.02' and '1.3.12'. The only other thing to do was to add the following to httpd.conf: LoadModule perl_module modules/ApacheModulePerl.dll Hope it turns out that easy for you. Cheers, Rob Visit our website at http://www.kalinabears.com.au - Original Message - From: Ron Reidy <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 14, 2001 2:18 AM Subject: mod_perl for Win32 + ActiveState Perl 5.6 (build 616) + Apache 1.3.12 > Hi, > > Is there a mod_perl available for the above > configuration? If not, do you have suggestions? > > Thank you. > > = > Ron Reidy > Oracle DBA > Reidy Consulting, L.L.C. > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/
Re: trouble with path_info
Matt Sergeant wrote: > Well you should read how Apache works. See > http://httpd.apache.org/docs/sections.html > > It should clear things up for you. Thank you, very interesting! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: cron for mod_perl?
Matt Sergeant wrote: > > Isn't forking off from Apache rather nasty? I saw something to that > > effect somewhere in the eagle book and on some web pages, but I think > > there are ways to do that without causing problems. > > Yes, its a pain. I suggest using the ways detailed below. My only problem > with those ways is that its not controlled from your application > generally, unless you write your own cron-a-like in Perl, and access your > datastore to get the configuration. Well, if I call the "check for things to do" URI every minute, then I'll be just fine. Many times, I'll just check and find nothing to do, but it'll be under "enough" application control. You might contrieve adding a cron entry as being "outside the application" though... I would really like putting this in a cleanup handler, but the problem I see is if I don't get any hit for too long (which might happen for an internal web site, say over the weekend), I might miss events. I'll probably have a combination of both approaches... > > I am on a Unix-like system, but I wanted the events to be updated by the > > web server itself, so that I could use the Apache::DBI cached connection > > to the DBMS (I want to store the events in there). > > The cached connection will be used, just as it would for the rest of your > application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and > executes faster too. And yes, you can restrict that URL to localhost, or > password protected. I was thinking of using wget with "-O /dev/null". :-) As for the cached database connection, I knew about that, but I was thinking of the forking approach (where there was no cached connection available (not that it couldn't be cached!)). -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Now, I do not completely understand this. Am I right when I say that > nothing on the filesystem is needed to locate a handler? > IMHO, a handler should be able to get its path_info resolved > without any filesystem access (thus, without any dependency on having a > valid DocumentRoot), and the current behavior would be a bug. Well you should read how Apache works. See http://httpd.apache.org/docs/sections.html It should clear things up for you. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: trouble with path_info
Matt Sergeant wrote: > > Hmm... Strange... It actually *works* at http://modperl.com/tree/ and I > > downloaded its source code from http://modperl.com/book/source/! > > Right, but the directory /tree might exist on their server - you never > know... I found the visible trigger. I didn't have a DocumentRoot *at all* in my configuration, but it didn't matter, as everything I have is served from handlers in sections (or even in the root of the configuration file!). If I would hit / directly (without the root PerlHandler), I would get a notice about /usr/htdocs not existing in my error log (that's the default DocumentRoot). I intented to verify the idea that having an actual /tree directory would help matters, so I proceeded to set a DocumentRoot in my configuration, figuring I'd then create the appropriate directory. Behold! Everything worked as in the book, without the directory! It just needed to have something *valid* as the DocumentRoot (I tried setting the DocumentRoot to something invalid, it doesn't work). Now, I do not completely understand this. Am I right when I say that nothing on the filesystem is needed to locate a handler? IMHO, a handler should be able to get its path_info resolved without any filesystem access (thus, without any dependency on having a valid DocumentRoot), and the current behavior would be a bug. I think the trouble might be more into Apache itself than in mod_perl. Right now, I consider my problem fixed, but I feel that this might be a real bug. I'll go submit something to the Apache bug tracking system later... -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: mod_perl for Win32 + ActiveState Perl 5.6 (build 616) + Apache1.3.12
Randy Kobes handles win32 binaries - i believe you can find the modperl 1.24 for use with apache 1.3.12 here: ftp://theoryx5.uwinnipeg.ca/pub/other/ppd/ApacheModulePerl-1.24_1.3.12.dll sterling On Tue, 13 Feb 2001, Ron Reidy wrote: > Hi, > > Is there a mod_perl available for the above > configuration? If not, do you have suggestions? > > Thank you. > > = > Ron Reidy > Oracle DBA > Reidy Consulting, L.L.C. > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ >
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Matt Sergeant wrote: > > > Pretty much what you've already found out - Apache has no "cron" like > > daemon. One way you can do it is fork off a sub-process and run some sort > > of Cron perl module (I think there's a Cron module on CPAN, or you can run > > cron-like features with POE). > > Hmm, too bad, that would have been easy to implement in the Apache core > request processing loop (it's build into the core of AOLserver). I'll > look to make sure, but I think this will be possible in Apache 2.0. > Anyway, that doesn't fix my problem for now. > > Isn't forking off from Apache rather nasty? I saw something to that > effect somewhere in the eagle book and on some web pages, but I think > there are ways to do that without causing problems. Yes, its a pain. I suggest using the ways detailed below. My only problem with those ways is that its not controlled from your application generally, unless you write your own cron-a-like in Perl, and access your datastore to get the configuration. > Perrin Harkins wrote: > > > The common way to do it is to just use the real cron facility (assuming you > > are on unix) and have it call a URL on your server using LWP. > > I am on a Unix-like system, but I wanted the events to be updated by the > web server itself, so that I could use the Apache::DBI cached connection > to the DBMS (I want to store the events in there). The cached connection will be used, just as it would for the rest of your application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and executes faster too. And yes, you can restrict that URL to localhost, or password protected. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: trouble with path_info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Matt Sergeant wrote: > > > > That would make the Apache::TreeBrowser example in the eagle book wrong, > > > isn't it? > > > > Yes, that example seems incorrect to me. > > Hmm... Strange... It actually *works* at http://modperl.com/tree/ and I > downloaded its source code from http://modperl.com/book/source/! Right, but the directory /tree might exist on their server - you never know... -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: cron for mod_perl?
> > Is there a way to have a Perl function called at some point in time, > > like I think AOLserver can do in Tcl (but I don't want to do either > > AOLserver or Tcl!)? > > > > I thought about checking the time in a PerlCleanupHandler, but this > > would be in each Apache subprocess and I want this to get called only > > once. The precision is not so important (unless we're talking hours > > later or something like that!). Matt Sergeant wrote: > Pretty much what you've already found out - Apache has no "cron" like > daemon. One way you can do it is fork off a sub-process and run some sort > of Cron perl module (I think there's a Cron module on CPAN, or you can run > cron-like features with POE). Hmm, too bad, that would have been easy to implement in the Apache core request processing loop (it's build into the core of AOLserver). I'll look to make sure, but I think this will be possible in Apache 2.0. Anyway, that doesn't fix my problem for now. Isn't forking off from Apache rather nasty? I saw something to that effect somewhere in the eagle book and on some web pages, but I think there are ways to do that without causing problems. Perrin Harkins wrote: > The common way to do it is to just use the real cron facility (assuming you > are on unix) and have it call a URL on your server using LWP. I am on a Unix-like system, but I wanted the events to be updated by the web server itself, so that I could use the Apache::DBI cached connection to the DBMS (I want to store the events in there). This seems good, exposing a URL that a cron job would fetch every minute (or something like that). I don't like much the idea of exposing an URL like that (could be used to cause a DoS, accessing the DBMS like crazy, but I guess this is a problem for any database-driven web site), but I can always restrict the URL to 127.0.0.1... Vivek Khera wrote: > Set up a handler and have a cron job "GET" the URL for it. Yeah, I think that's what I'll do! > You already have the "GET" program from the lwp package while > installing mod_perl. I have the mod_perl RPM that comes with Red Hat, and I can't find the LWP anywhere. Not that I can't install it or use wget instead... Thanks everyone! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: compiling mod_perl without root...
Hi there, On Tue, 13 Feb 2001, Joseph Crotty wrote: > How do I compile so the apache perl modules get > installed in a place of my choosing??? You can just copy them there yourself. Then all you have to do is set the @INC paths so they can be found at runtime. I think you'll find all you need about that in the Guide. http://perl.apache.org/guide But you still need to be root to attach to port 80, so root has to start the server unless it's only going to listen to ports > 1024. 73, Ged.
RE: compiling mod_perl without root...
Ged, Thanks for the reply. The heart of the problem is we need to compile apache/mod_perl from source(i.e. apache_1.3.14.tar.gz and mod_perl1-1.25.tar.gz) which lives in cvs. The machine cvs resides on is not the target machine for the apache/mod_perl install. The plan is to compile it and install it in a directory in cvs current, and then package the whole thing up using the SUN package utilities. To complicate matters we need to build apache/mod_perl from the cvs source under a group other than root. So I run as someone other then root, the compile goes fine, but when make install comes I get the following: Warning: You do not have permissions to install into /usr/local/lib/perl5/site_perl/5.6.0 at /usr/local/lib/perl5/5.6.0/ExtUtils/Install.pm line 62. Cannot forceunlink /usr/local/man/man3/Apache.3: Permission denied at /usr/local/lib/perl5/5.6.0/File/Find.pm line 475 make: Fatal error: Command failed for target `pure_site_install' I assume its upset because /usr/local/lib/perl5/site_perl/5.6.0 is drwxr-xr-x 30 root other 2560 Nov 29 11:28 5.6.0 I don't know where to get a binary distribution of apache_x.x.x/mod_perl-x.x so it looks like I am stuck if I want to compile with other than rootor else edit the makefile.PL which sounds dreadful. -Original Message- From: G.W. Haywood [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 13, 2001 2:21 PM To: Joseph Crotty Cc: [EMAIL PROTECTED] Subject: Re: compiling mod_perl without root... Hi there, On Tue, 13 Feb 2001, Joseph Crotty wrote: > How do I compile so the apache perl modules get > installed in a place of my choosing??? You can just copy them there yourself. Then all you have to do is set the @INC paths so they can be found at runtime. I think you'll find all you need about that in the Guide. http://perl.apache.org/guide But you still need to be root to attach to port 80, so root has to start the server unless it's only going to listen to ports > 1024. 73, Ged.
Re: trouble with path_info
Matt Sergeant wrote: > > > I'm really stumped with that one. How come Apache::Registry gets the > > > right information and I don't??? I tried doing the exact same thing, to > > > no avail. > > Because Apache::Registry has a real file, so the fixup handler puts the > right thing in path_info. Without a real file and a fixup handler you > don't get the right information in path_info, you have to figure it out by > hand. As a side-note, I guess it's most probably the translation handler that puts the right thing in path_info. My workaround is a fixup handler, since there is no actual filename to translate, and you can't put a translation handler just in a anyway. Thanks for your help! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: trouble with path_info
Matt Sergeant wrote: > > That would make the Apache::TreeBrowser example in the eagle book wrong, > > isn't it? > > Yes, that example seems incorrect to me. Hmm... Strange... It actually *works* at http://modperl.com/tree/ and I downloaded its source code from http://modperl.com/book/source/! Doug, is there something you forgot? Errata? Or, again, something we are forgetting? I made a PerlFixUpHandler that simply shave $r->location from the front of $r->path_info, if you install it in the same directory as Apache::TreeBrowser (or other similarly written handler), it make them work fine. > PS: Please don't post large attachments to the list in future - send us a > link to a place we can see the code you are using on the web. Sorry! I took extra care to make the package as small as possible, but I understand the rule, thanks! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
baffled by vs. problem
I ran into a problem trying to get MysqlTool running under mod_perl
using the instructions in the included README, so I've broken down my
problem into a simple Hello World script (modified from the one in
the Eagle book) that demonstrates the same problem.
The problem I'm having is that I can get directives to
pass control to a mod_perl handler OK, but if I try to switch it to a
, it stops working.
I have an Apache::Hello.pm that just displays the values of the
MOD_PERL and GATEWAY_INTERFACE env vars.
I have a CGI script /hello/index.cgi that just calls
Apache::Hello::handler. This CGI works fine ( $ENV{MOD_PERL} and
$ENV{GATEWAY_INTERFACE} as expected for outside of mod_perl ).
When I put the following in my httpd.conf ...
SetHandler perl-script
PerlHandler Apache::Hello
... and access the same URL, mod_perl handles it. But if I change the
entry in httpd.conf to ...
SetHandler perl-script
PerlHandler Apache::Hello
... it goes back to executing the CGI.
I must be missing something obvious, right?
Ray
P.S. In case it matters, this is Perl 5.00503, Apache 1.3.17,
mod_perl 1.25 running on Red Hat 6.2.
Re: trouble with path_info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Matt Sergeant wrote: > > > > Does anyone has an idea about this? I think I have proper behavior from > > > my perl handler by installing it at the root of the server, but this is > > > no real solution! > > > > > > What I am doing wrong here??? > > > > > > > I'm really stumped with that one. How come Apache::Registry gets the > > > > right information and I don't??? I tried doing the exact same thing, to > > > > no avail. > > > > Because Apache::Registry has a real file, so the fixup handler puts the > > right thing in path_info. Without a real file and a fixup handler you > > don't get the right information in path_info, you have to figure it out by > > hand. > > That would make the Apache::TreeBrowser example in the eagle book wrong, > isn't it? Yes, that example seems incorrect to me. PS: Please don't post large attachments to the list in future - send us a link to a place we can see the code you are using on the web. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
mod_perl for Win32 + ActiveState Perl 5.6 (build 616) + Apache 1.3.12
Hi, Is there a mod_perl available for the above configuration? If not, do you have suggestions? Thank you. = Ron Reidy Oracle DBA Reidy Consulting, L.L.C. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Re: trouble with path_info
Matt Sergeant wrote: > > Does anyone has an idea about this? I think I have proper behavior from > > my perl handler by installing it at the root of the server, but this is > > no real solution! > > > > What I am doing wrong here??? > > > > > I'm really stumped with that one. How come Apache::Registry gets the > > > right information and I don't??? I tried doing the exact same thing, to > > > no avail. > > Because Apache::Registry has a real file, so the fixup handler puts the > right thing in path_info. Without a real file and a fixup handler you > don't get the right information in path_info, you have to figure it out by > hand. That would make the Apache::TreeBrowser example in the eagle book wrong, isn't it? Doug, is there something I'm missing about installing Apache::TreeBrowser? -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
RE: losing pnotes on directory "index" file
> -Original Message- > From: Vivek Khera [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 13, 2001 2:31 PM > To: Mod Perl List > Subject: losing pnotes on directory "index" file > > > I just noticed that if I request a URL by its directory, > http://hostname/bar/ that the $r->pnotes() is lost from earlier > handlers. > > Detail: I use AuthCookie to pull a session from the database and set > a few things in $r->pnotes. Later the "index.mlm" file that is > configured as the file to use on a directory URL tries to pull > something from there, it is missing. > > I'm assuming that since the index.mlm file is "run" as a subrequest, > that somehow the pnotes go away from the main request. > > Is this indeed what is going on and is it the expected behavior? I'm > thinking my functions could chase up $r->prev to find the right > pnotes as a work around. that sounds right... don't forget to check that $r->prev exists, too, in case they access index.mlm directly HTH --Geoff > > Comments? >
NISPlus-0.06-alpha problem
Hi,
I recently build Apache_1.3.14 with Mod_perl-1.24_01 on Solaris system
when I testing NIS+ portion I got terminal hung in Module Table.pm
The code actually hung is in sub colnames. I also cut that portion onto
here.
The line that atually waitting for return is the bolded blue line(which I
don't have a clue what it is doing.)
I was using interactive debugger to be able to isloate to this point.
Is there any person can point me in the right direction?
I'll appreciate any help
Thanks,
PC
sub colnames
{
my($me) = shift;
my($ret, $res);
if (!defined($me->{'colnames'}))
{
($ret, $res) = Net::NISPlus::table_info($me->fullPath);
if ($ret != 0)
{
Warning("colnames error: ", niserror($ret), "\n");
return ();
}
else
{
$me->{'colnamesarr'} = $res->{'ta_cols'};
foreach ($[..$#{@{$me->{'colnamesarr'}}})
{
$me->{'colnameshash'}->{$me->{'colnamesarr'}->[$_]} = $_;
}
}
}
return(@{$me->{'colnamesarr'}}) if wantarray;
return($me->{'colnameshash'});
}
losing pnotes on directory "index" file
I just noticed that if I request a URL by its directory, http://hostname/bar/ that the $r->pnotes() is lost from earlier handlers. Detail: I use AuthCookie to pull a session from the database and set a few things in $r->pnotes. Later the "index.mlm" file that is configured as the file to use on a directory URL tries to pull something from there, it is missing. I'm assuming that since the index.mlm file is "run" as a subrequest, that somehow the pnotes go away from the main request. Is this indeed what is going on and is it the expected behavior? I'm thinking my functions could chase up $r->prev to find the right pnotes as a work around. Comments?
Re: cron for mod_perl?
> "PP" == Pierre Phaneuf <[EMAIL PROTECTED]> writes: PP> Is there a way to have a Perl function called at some point in time, PP> like I think AOLserver can do in Tcl (but I don't want to do either PP> AOLserver or Tcl!)? Set up a handler and have a cron job "GET" the URL for it. You already have the "GET" program from the lwp package while installing mod_perl.
Re: cron for mod_perl?
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > > Is there a way to have a Perl function called at some point in time, > like I think AOLserver can do in Tcl (but I don't want to do either > AOLserver or Tcl!)? > > I thought about checking the time in a PerlCleanupHandler, but this > would be in each Apache subprocess and I want this to get called only > once. The precision is not so important (unless we're talking hours > later or something like that!). > > I thought of having a table of jobs in my PostgreSQL database and > (carefully avoiding race conditions with transactions/locking) checking > if the next job was due to be run, but that doesn't "smell" very good. I > could run the query only on the condition that a minute has passed since > the last time we did it, but still, I'm not sure. > > I would like to know if anyone already did that or have any idea on how > to do that more properly? Pretty much what you've already found out - Apache has no "cron" like daemon. One way you can do it is fork off a sub-process and run some sort of Cron perl module (I think there's a Cron module on CPAN, or you can run cron-like features with POE). -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: trouble with path_info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Pierre Phaneuf wrote: > > Does anyone has an idea about this? I think I have proper behavior from > my perl handler by installing it at the root of the server, but this is > no real solution! > > What I am doing wrong here??? > > > I'm really stumped with that one. How come Apache::Registry gets the > > right information and I don't??? I tried doing the exact same thing, to > > no avail. Because with Apache::Registry the "file" actually exists and has a 'real' URI ... so it's easy to determine which parts are the scriptname and which parts are 'extra path info' ... this is quite likely done outside of mod_perl by the default handlers (sorry, no time to lookup the which request stages involved)... I would _guess_ that with a handler, it's not so clear... it would seem that script_name should be whatever you have in the directive, and anything else would be path_info ...
Re: Setting 'Location' header
On Tue, 13 Feb 2001, Stathy Touloumis wrote: > This code does not seem to work whether in a handler or when using a Mason > component. I have tried several variations with different versions of > mod_perl to no avail. Can anyone shed some light? > > my $head = $r->headers_out; > $head->set( Location=> '/index.html' ); > $head->set( Target=> '_top' ); > $r->send_http_header; The Mason FAQ has a good example of how to do a redirect from a Mason component. The same code (minus the Mason specific stuff) works fine under mod_perl. You're missing setting the status, which is probably the main problem. Here's a link to the Mason FAQ: http://www.masonhq.com/docs/faq/#How_do_I_do_an_external_redirect -dave /*== www.urth.org We await the New Sun ==*/
Setting 'Location' header
This code does not seem to work whether in a handler or when using a Mason component. I have tried several variations with different versions of mod_perl to no avail. Can anyone shed some light? my $head = $r->headers_out; $head->set( Location=> '/index.html' ); $head->set( Target=> '_top' ); $r->send_http_header; Thanks!
cron for mod_perl?
Is there a way to have a Perl function called at some point in time, like I think AOLserver can do in Tcl (but I don't want to do either AOLserver or Tcl!)? I thought about checking the time in a PerlCleanupHandler, but this would be in each Apache subprocess and I want this to get called only once. The precision is not so important (unless we're talking hours later or something like that!). I thought of having a table of jobs in my PostgreSQL database and (carefully avoiding race conditions with transactions/locking) checking if the next job was due to be run, but that doesn't "smell" very good. I could run the query only on the condition that a minute has passed since the last time we did it, but still, I'm not sure. I would like to know if anyone already did that or have any idea on how to do that more properly? -- "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -- Edsger W. Dijkstra
compiling mod_perl without root...
HI all, Situation: I have compiled and installed apache_1.3.14/mod_perl-1.24 using makepl_args.mod_perl. All this was done as root. But now of course that I have the cgi software package dialed in and ready to delivere to production my boss informs me that we need to be able to compile and delivere without root or else by-by mod_perl. Problem: The whole compile is being done inside of CVS. That is the apache is installed in usr/local/apache under current. But the make install wants to "install" the apache perl modules, Apache.pm Constants.pm etc, in the standard perl library. How do I compile so the apache perl modules get installed in a place of my choosing??? Thanks, Joe Crotty
Re: trouble with path_info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Pierre Phaneuf wrote: > > Does anyone has an idea about this? I think I have proper behavior from > my perl handler by installing it at the root of the server, but this is > no real solution! > > What I am doing wrong here??? > > > I'm really stumped with that one. How come Apache::Registry gets the > > right information and I don't??? I tried doing the exact same thing, to > > no avail. Because Apache::Registry has a real file, so the fixup handler puts the right thing in path_info. Without a real file and a fixup handler you don't get the right information in path_info, you have to figure it out by hand. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: trouble with path_info
Pierre Phaneuf wrote:
Does anyone has an idea about this? I think I have proper behavior from
my perl handler by installing it at the root of the server, but this is
no real solution!
What I am doing wrong here???
> I'm really stumped with that one. How come Apache::Registry gets the
> right information and I don't??? I tried doing the exact same thing, to
> no avail.
>
> I built the smallest possible testcase I could (attached to this
> message, just fix the /home/pp/tmp in httpd.conf and startup.pl into
> wherever you unpack this, if you want to try it out).
>
> Ideally, http://localhost/perl/test/foo and http://localhost/test/foo
> would both say the same thing ("path_info: /foo"). On my machine, they
> don't.
>
> http://localhost/virtual/ should also say "Path information =/" at the
> bottom. On my machine, it says "Path information =/virtual/".
--
"World domination. Fast." -- Linus Torvalds
Re: Antwort: Repost: Anyone using "virtual server" for mod_perl hosts?
On 13 Feb 2001, at 16:45, Stas Bekman wrote: > > Now, has anyone tried this services? Do I have to worry about anything? > > Why didn't Stas list them in his article? -- they don't appear in the > > Guide either -- Do they have a fundamental or practical flaw I can't > > see? > > cauze I've never tried these and nobody submitted them to me. I've sent a > request to the list something like 4 months before publishing the article, > I've used all the information I've received. I have used iserver for about the last 4-5 years. In addition to Stas's mod_perl guide he has a lot of info on his site for webmasters. Some of Stas's other webmaster info is on the iserver site with credits and links to his site. I sent an email (see below) to iserver telling them that Stas was going to publish the article. They responded to me but apparently never followed up. iserver has been bought out at least 2 times I think; they've probably got too many "employees". I think Martin did an excellent job in describing their services. I've been more than happy with iserver although in a few cases recently they've made changes without informing us customers in advance (and so sites went down through no fault of our own). I think the key is that the sites cannot be too active. http://www.iserver.com/products/virtual/faq.html > Our Virtual Servers are designed to handle a low to medium hit load > (under 100,000 hits a day). If a site begins to receive over 100,000 > hits a day, web page response will begin to be affected. Those who > have web sites experiencing over 100,000 hits per day should consider > a Dedicated Server. A Dedicated Server can accommodate well over 1 > million hits a day. At iserver I've created (umm ... used a lot of cpan :) some nice applications in mod_perl that would be cumbersome at best with standard cgi. But we put intensive sites on their own boxes. Peter > From: Peter J. Schoenster <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: (Fwd) Re: Building a ModPerl ISP for you! > Send reply to:[EMAIL PROTECTED] > Date sent:Fri, 10 Nov 2000 09:45:33 -0700 > > Hi, > > I don't know if to send this to sales (If such an email exists at > iserver) or support ... I do know that support reads and responds ... > so please forward this to a person in the company who might want to > respond to this article. I always give a thumbs up for iserver when > such things appear in the list. You might note that you used some > examples from Stas on installing perl modules on your site . > > Peter > > --- Forwarded message follows --- > Date sent:Fri, 10 Nov 2000 16:13:55 +0100 (CET) > From: Stas Bekman <[EMAIL PROTECTED]> > To: Joshua Chamas <[EMAIL PROTECTED]> > Copies to:Mod Perl <[EMAIL PROTECTED]> > Subject: Re: Building a ModPerl ISP for you! --- "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick
Re: "idea" modules info
Mark Imbriaco wrote: > > > > What is the usual process for one that would like to help with a "i" > > > > module? Is there any code done, or some message/thread that I could be > > > > pointed to, discussing the idea, things like that? > > > > > > I developed some code to do this a VERY long time ago, but the code was > > > quite specific to my needs (virtual hosting) and I never got around to > > > generalizing it. If you're interested in taking over the module list > > > entry for this one, I have absolutely no problems with that. > > > > Send it to me, I'll take a look! I don't garantee I can take it over, > > but if I use it, I probably will be able to maintain it (as part of my > > day job). > > I don't even have the code any more -- it was written three jobs ago and > the company it was written for doesn't even exist anymore. :) Sorry. Okay, no problem. Could you write up a quick summary of how it worked (or how a rewrite should work)? If that was discussed on this mailing list already, you could give me a pointer to a thread instead... -- "The only 'intuitive' interface is the nipple. After that, it's all learned." -- [EMAIL PROTECTED] (on user interfaces)
Re: "idea" modules info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > Mark Imbriaco wrote: > > > > What is the usual process for one that would like to help with a "i" > > > module? Is there any code done, or some message/thread that I could be > > > pointed to, discussing the idea, things like that? > > > > I developed some code to do this a VERY long time ago, but the code was > > quite specific to my needs (virtual hosting) and I never got around to > > generalizing it. If you're interested in taking over the module list > > entry for this one, I have absolutely no problems with that. > > Send it to me, I'll take a look! I don't garantee I can take it over, > but if I use it, I probably will be able to maintain it (as part of my > day job). I don't even have the code any more -- it was written three jobs ago and the company it was written for doesn't even exist anymore. :) Sorry. -Mark -- "The big question is whether the planet will disappear in the twinkling of an eye. It is astonishingly unlikely that there is any risk - but I could not prove it." - John Nelson
Re: "idea" modules info
Mark Imbriaco wrote: > > What is the usual process for one that would like to help with a "i" > > module? Is there any code done, or some message/thread that I could be > > pointed to, discussing the idea, things like that? > > I developed some code to do this a VERY long time ago, but the code was > quite specific to my needs (virtual hosting) and I never got around to > generalizing it. If you're interested in taking over the module list > entry for this one, I have absolutely no problems with that. Send it to me, I'll take a look! I don't garantee I can take it over, but if I use it, I probably will be able to maintain it (as part of my day job). -- "How should I know if it works? That's what beta testers are for. I only coded it." -- Linus Torvalds
Re: "idea" modules info
On Tue, 13 Feb 2001, Pierre Phaneuf wrote: > I *could* be willing to implement the following two modules, if the > ideas happen to match what I think I would need. > > > RoleAuthz i Role-based authorizationDOUGM > > ConfigDBI i Config via DBI andMARKIM > > What is the usual process for one that would like to help with a "i" > module? Is there any code done, or some message/thread that I could be > pointed to, discussing the idea, things like that? I developed some code to do this a VERY long time ago, but the code was quite specific to my needs (virtual hosting) and I never got around to generalizing it. If you're interested in taking over the module list entry for this one, I have absolutely no problems with that. -Mark -- "The big question is whether the planet will disappear in the twinkling of an eye. It is astonishingly unlikely that there is any risk - but I could not prove it." - John Nelson
"idea" modules info
Speaking of modules... I *could* be willing to implement the following two modules, if the ideas happen to match what I think I would need. > RoleAuthz i Role-based authorizationDOUGM > ConfigDBI i Config via DBI andMARKIM What is the usual process for one that would like to help with a "i" module? Is there any code done, or some message/thread that I could be pointed to, discussing the idea, things like that? Thanks for the info! -- "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -- Edsger W. Dijkstra
Re: revising Apache::* modules list
I know the status of at least one... Apache::WebSQL can be found at ftp://ftp.nhgri.nih.gov/pub/software/misc Although it originated with me and Jason, the software is maintained now by Joe and Anthony at NHGRI. I don't think they have any time to put it on CPAN though. If anyone wishes to volunteer to take on the project, they are welcome to do so. Apache::WebSQL has served its purpose -- to allow us to migrate away from Sybase's WebSQL without changing any legacy websql coding now that Sybase has dropped the product into oblivion. Thus, it's not really going to go much farther unless others require more sophisticated emulation from it. At 10:40 PM 2/13/01 +0800, Stas Bekman wrote: >Hi, > >While compiling the Apache::* modules chapter for the book, I've found >that these modules aren't on the Apache::* list: > >Apache::WAP::MailPeek DBRIAN >Apache::WAP::AutoIndex DBRIAN > >probably there are more of them... > >Then there are modules that cannot be found on CPAN and probably some of >them should be removed from this list. Note that it's normal for modules >with status i not to be on CPAN. MPB (mod_perl book) marked modules aren't >there as well, which is OK. But what about the rest? > >All these couldn't be found on CPAN: > >* PerlHandler's >AdBannercdpfAd banner serverCHOLET >AddrMunge bdpfMunge email addresses in webpages MJD >BBS cdpOBBS like System for Apache MKOSS >Cachet i OutputChain with cachingMERLYN >Dir i OO (subclassable) mod_dir replacement DOUGM >Forward bdpOOutputChain like functionality MPB >FTP i Full-fledged FTP proxy PMKANE >Magick bdpfImage conversion on-the-fly MPB >NavBar bdpONavigation bar generatorMPB >RobotRules cdpfEnforce robot rules (robots.txt)PARKER >TarGzip c ZENIN >VhostSandwich cdpfVirtual host layered document maker MARKC >WDB bdpfDatabase query/edit tool using DBI JROWE >WebSQL cdpOAdaptation of Sybase's WebSQL GUNTHER > >* PerlHeaderParserHandler's >AgentDeny cdpfDeny abusive User-AgentsROBH > >* PerlAuthenHandler's >AuthAny bdpfAuthenticate with any username/password MPB >AuthenGSS cdpfGeneric Security Service (RFC 2078) DOUGM >AuthenRaduisbdpfAuthentication via a Radius server DANIEL >DCELoginbdpfObtain a DCE login context DOUGM >TicketAccessbdpOTicket based access/authentication MPB > >* PerlAuthzHandler's >AuthzAgebmpfAuthorize based on age APML >AuthzDCEcdpfDFS/DCE ACL based access controlDOUGM >AuthzGender bdpfAuthorize based on gender MPB >AuthzSSLbdpfAuthorize based on client cert MPB >RoleAuthz i Role-based authorizationDOUGM > >* PerlAccessHandler's >BlockAgent bdpfBlock access from certain agentsMPB >DayLimitbmpfLimit access based on day of week MPB >SpeedLimit bdpfControl client request rate MPB > > >* PerlTypeHandler's >AcceptLanguage cdpfSend file type based on language pref ROBH >MIMEbdcfPerl implementation of mod_mime MPB >MimeDBI bdpfType mapping from a DBI databaseMPB > > >* PerlTransHandler's(May also include a PerlHandler) >AdBlocker bdpfBlock advertisement images MPB >AnonProxy bdpfAnonymizing proxy MPB >ChecksumbdpfManage document checksum trees MPB >DynaRPC i Dynamically translate URIs into RPCsDOUGM >StripSessionbdpfStrip session info from URI MPB >ProxyCache i Caching proxy DOUGM >LowerCaseGETs bdpfLowercase URI's when needed PLISTER >MsqlProxy bmpfTranslate URI's into mSQL queries APML > >* PerlFixupHandler's >HttpEquiv bdpfHTML HTTP-EQUIV tags to HTTP headersROBH >Timeit bmpfBenchmark PerlHandlers APML > >* PerlLogHandler's >LogMail bdpfLog certain requests via email MPB >WatchDogc Look for problematic URIs DOUGM > >* Server Configuration >ConfigLDAP i Config via LDAP and MARKK >ConfigDBI i Config via DBI andMARKIM > >* Database >Sybase::DBlib bmpOPersistent DBlib connection mgmt. BMILLET > >* Interfaces and integration with Apache C structures and modules >Apache SmcOInterface to request_rec struct + API APML >CmdParmsSmcOInterface to Apache cmd_parms structAPML >Command
revising Apache::* modules list
Hi, While compiling the Apache::* modules chapter for the book, I've found that these modules aren't on the Apache::* list: Apache::WAP::MailPeek DBRIAN Apache::WAP::AutoIndex DBRIAN probably there are more of them... Then there are modules that cannot be found on CPAN and probably some of them should be removed from this list. Note that it's normal for modules with status i not to be on CPAN. MPB (mod_perl book) marked modules aren't there as well, which is OK. But what about the rest? All these couldn't be found on CPAN: * PerlHandler's AdBannercdpfAd banner serverCHOLET AddrMunge bdpfMunge email addresses in webpages MJD BBS cdpOBBS like System for Apache MKOSS Cachet i OutputChain with cachingMERLYN Dir i OO (subclassable) mod_dir replacement DOUGM Forward bdpOOutputChain like functionality MPB FTP i Full-fledged FTP proxy PMKANE Magick bdpfImage conversion on-the-fly MPB NavBar bdpONavigation bar generatorMPB RobotRules cdpfEnforce robot rules (robots.txt)PARKER TarGzip c ZENIN VhostSandwich cdpfVirtual host layered document maker MARKC WDB bdpfDatabase query/edit tool using DBI JROWE WebSQL cdpOAdaptation of Sybase's WebSQL GUNTHER * PerlHeaderParserHandler's AgentDeny cdpfDeny abusive User-AgentsROBH * PerlAuthenHandler's AuthAny bdpfAuthenticate with any username/password MPB AuthenGSS cdpfGeneric Security Service (RFC 2078) DOUGM AuthenRaduisbdpfAuthentication via a Radius server DANIEL DCELoginbdpfObtain a DCE login context DOUGM TicketAccessbdpOTicket based access/authentication MPB * PerlAuthzHandler's AuthzAgebmpfAuthorize based on age APML AuthzDCEcdpfDFS/DCE ACL based access controlDOUGM AuthzGender bdpfAuthorize based on gender MPB AuthzSSLbdpfAuthorize based on client cert MPB RoleAuthz i Role-based authorizationDOUGM * PerlAccessHandler's BlockAgent bdpfBlock access from certain agentsMPB DayLimitbmpfLimit access based on day of week MPB SpeedLimit bdpfControl client request rate MPB * PerlTypeHandler's AcceptLanguage cdpfSend file type based on language pref ROBH MIMEbdcfPerl implementation of mod_mime MPB MimeDBI bdpfType mapping from a DBI databaseMPB * PerlTransHandler's(May also include a PerlHandler) AdBlocker bdpfBlock advertisement images MPB AnonProxy bdpfAnonymizing proxy MPB ChecksumbdpfManage document checksum trees MPB DynaRPC i Dynamically translate URIs into RPCsDOUGM StripSessionbdpfStrip session info from URI MPB ProxyCache i Caching proxy DOUGM LowerCaseGETs bdpfLowercase URI's when needed PLISTER MsqlProxy bmpfTranslate URI's into mSQL queries APML * PerlFixupHandler's HttpEquiv bdpfHTML HTTP-EQUIV tags to HTTP headersROBH Timeit bmpfBenchmark PerlHandlers APML * PerlLogHandler's LogMail bdpfLog certain requests via email MPB WatchDogc Look for problematic URIs DOUGM * Server Configuration ConfigLDAP i Config via LDAP and MARKK ConfigDBI i Config via DBI andMARKIM * Database Sybase::DBlib bmpOPersistent DBlib connection mgmt. BMILLET * Interfaces and integration with Apache C structures and modules Apache SmcOInterface to request_rec struct + API APML CmdParmsSmcOInterface to Apache cmd_parms structAPML Command bmcOInterface to Apache command_rec struct APML Handler bmcOInterface to Apache handler_rec struct APML * HTTP Method handlers PATCH bdpfHTTP PATCH method handler MPB PUT cdpfHTTP PUT method handler SORTIZ * Misc Byterun i Run Perl bytecode modules DOUGM SafeampOAdaptation of "safecgiperl" APML Servlet ampOInterface to the Java Servlet engineIKLUFT State i Powerful state engine RSE Upload amcOFile upload class APML Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacke
Re: Problem with libapreq on RH 6.2
Hi, your system may have perl libraries installed in more than one place -- set the PERLLIB variable in the root profile to all the places perl modules may be (if you have multiple copies of perl, just stick together the @INC from the different ones, or pick one that works...). here's an example from a root .bash_profile on a machine that had that problem: PERLLIB="/usr/lib/perl5/5.6.0/i386linux:/usr/lib/perl5/5.6.0:/usr/lib/perl5/site_perl/5.6.0/i386-linux:/usr/lib/perl5/site_perl/5.6.0:/usr/lib/perl5/site_perl:/usr/local/lib/perl5/5.6.0/i586linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i586-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:.:/usr/local/lib/perl5/5.6.0/i686-linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i686-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:." export ... PERLLIB ... -Noam x Andy Williams wrote: > I have seen mails flying around about a problem on RH using RPMs for > Apache/mod_perl and libapreq. > So I decided to build Apache (1.3.17), mod_perl (1.25) and libapreq > (0.31_03) from source. > > All installed without any suggestion of a problem. However, when I try to > run Apache (configured to use OpenInteract 1.05) I get the following > error: > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Request : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Request/Request.so' > for module Apache::Request: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 4. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Cookie : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Cookie/Cookie.so' > for module Apache::Cookie: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 5. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > Does anyone have any idea why this is happening? > > TIA > > Andy > > > > "Talkie Toaster: Given that God is infinite, and that the > Universe is also infinite, would you like a toasted tea > cake?" > >
Re: [OT] Re: Repost: Anyone using "virtual server" for mod_perl hosts?
Tim Bunce writes: > On Tue, Feb 13, 2001 at 11:28:20AM +, Malcolm Beattie wrote: > > > > you'll see that IBM reckons you can get down to $500 per server > > (disk not included) by putting 2500 instances on a brand new fancy > > $1.2 million z900. > > Assuming all the virtual linux servers were fully loaded with tasks > (say apache+mod_perl as an example)... What kind of tradition Intel > platform performance would each virtual linux instance be equivalent to? > > e.g., CPU: ~600MHz PIII? Heck, if IBM would just get a test system on our floor like they've been promising for months, I'd be able to find out. It depends on how the load spreads between the servers. It's much the same problem as determining how many users you can put on a large multi-user system and how much real disk space you need. Say you have 1 users on a machine: it may be that only 500 or 1000 are active at any one time. It depends on the environment. Similarly, you can give people large quotas in many environments (POP servers, some web hosting, some home filestore) because, on average, people only use a small fraction. The problems are similar (but not the same) for running multiple virtual servers on one system. They're similar because you have overallocation and "competing" for shared resources with potential bursty and asymmetric behaviour that the system has to smooth out. They're different because the same rule of thumb numbers don't apply (or at least they apply but only "one level up"). If you have say 100 systems with 1000 users/clients/whatever for each then you'd get the same "hit rate" (in some abstract sense) from 1 user of each virtual server doing 1 hit as from 100 users hitting only one server. In the former case, you've got the system overhead of using memory and scheduling for 100 different kernels; in the second case, 99 of the kernels are sitting idle, paged out, unscheduled and barely affecting the machine at all. All I can do is basic sums on the hardware figures (available in my slides) such as one G6/z900 CPU having roughly 16 times the cache and memory bandwidth of an Intel CPU and needing zero CPU for most of the I/O path which is all offloaded onto SAP/channels/OSA. Until IBM get me that test system, my best guesstimate/hope is that if we were to put 150 virtual servers on a 3-way G5/G6 system with 16 channels and 1 in 10 active at any instant then, if those systems that are active all happen to need maximum CPU at the same time, each is getting about 120MHz-worth of CPU and the equivalent of a fast-wide SCSI bandwidth to disk except that there's almost zero CPU cost for I/O to either disk or network. In general, CPU use (and I/O and memory) will be smoother and scheduled across the entire system so that bursty behaviour for CPU, I/O and memory will all be smoothed out. That's the theory and, at the moment, I've convinced myself that it could theoretically hold in practice too but I've no first-hand evidence (other than other big sites like Telia, the big German ISP and so on going Linux/390). > And what about network i/o? Would the z900 network i/o be a bottleneck > if all the virtual servers were blasting away? Almost certainly not. You can put 24 OSA-Express Gigabit ports (12 cards) into a z900, each taking one of your maximum of 256 channels. See my slides. --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services
Re: [OT] Re: Repost: Anyone using "virtual server" for mod_perl hosts?
On Tue, Feb 13, 2001 at 11:28:20AM +, Malcolm Beattie wrote: > > you'll see that IBM reckons you can get down to $500 per server > (disk not included) by putting 2500 instances on a brand new fancy > $1.2 million z900. Assuming all the virtual linux servers were fully loaded with tasks (say apache+mod_perl as an example)... What kind of tradition Intel platform performance would each virtual linux instance be equivalent to? e.g., CPU: ~600MHz PIII? And what about network i/o? Would the z900 network i/o be a bottleneck if all the virtual servers were blasting away? Tim.
Re: [OT] Re: Repost: Anyone using "virtual server" for mod_perl hosts?
G.W. Haywood writes: > On Mon, 12 Feb 2001, Malcolm Beattie wrote: > > > > you can run *thousands* of separate Linux images on a S/390 > > How much, to the nearest order of magnitude, does a S/390 cost? How long is a piece of string? An S/390 can be anything from about $100 on ebay for an extremely old one which would cost more in power, space and cooling and do less in performance than any reasonable person would want unless they're *really* hooked on history and blinkenlights. At the top end you can pay $5 million or more for a top of the range z900 fully kitted out. More usefully, I'll say that I'm after a system which costs around 1000 GBP per virtual server (that would be $1000 at computing prices of $1 = 1GBP). The question is how large a system I have to get to bring down the per-virtual-server price that far. I'm hoping that 150-200 would do the trick but I'm (a) hoping to pay extremely low academic prices and (b) probably being over-optimistic. If you look at http://www-1.ibm.com/servers/eserver/zseries/linuxconfig/ you'll see that IBM reckons you can get down to $500 per server (disk not included) by putting 2500 instances on a brand new fancy $1.2 million z900. On one hand, I'd guess you may need to pay for some upgrading if they aren't very lightly used servers but on the other hand, no one ever pays list price (I'm reliably informed). On the gripping hand, it's very difficult getting hold of pricing information at all on these things (as mentioned in my last slide, I think) which is one of the big problems. --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services
OT - linux "sysadmin" mailing list recommended ?
Can anybody recommend a list I can subscribe to which covers general Linux system administration issues and problems, to complement this one ? thanks Rod
Re: Help with Apache::SubProcess needed.
Thanks very much. That did the trick. Steve On 13 Feb 2001, at 17:04, Stas Bekman wrote: > On Mon, 12 Feb 2001, Stephen Gailey wrote: > > > Help with Apache::SubProcess needed. > > > > I have tried the example for running a long duration task from Mod > > Perl, as found in the performance tuning guide, but I get the > > following error: > > > > [error] Can't locate object method "cleanup_for_exec" > > via package "Apache" at > > /usr/local/apachessl/handlers/wrapper_handler line 22 > > > > I am using the script right off the page and I have downloaded (from > > CPAN) and installed SubProcess. any ideas? > > I've released a new version of the guide, but Doug didn't have a > chance to release a new version of this module with a new function > yet. Just apply this patch and recompile: > > -- SubProcess.xs.orig Sat Sep 25 19:17:12 1999 > +++ SubProcess.xs Tue Dec 19 21:03:22 2000 > @@ -103,6 +103,14 @@ > XPUSHs(io_hook(ioep, io_hook_read)); > } > > + > +void > +ap_cleanup_for_exec(r) > +Apache r > + > +CODE: > +ap_cleanup_for_exec(); > + > int > ap_call_exec(r, pgm=r->filename) > Apache r > > _ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ > > >
Re: Stop button (was: Re: General Question)
On Sun, 11 Feb 2001, Bill Moseley wrote:
> I don't know why I have to learn this fresh again each time -- it appears
> I'm confusing mod_perl and mod_cgi.
>
> Let's see if I have this right. Under mod_perl and apache >= 1.3.5 if the
> client drops the connection Apache will ignore it (well it might print an
> info message to the log file about "broken pipe"). This means a running
> mod_perl script will continue to run to completion, but the $r->prints go
> nowhere.
>
> The old Apache behavior of killing your running script can be restored
> using Apache::SIG -- which is something you would not want to use if you
> were doing anything besides displaying content, I'd think.
>
> $r->connection->aborted can be used to detect the aborted connection (as
> Stas shows in the Guide). That sounds like a better way to deal with
> broken connections.
>
> Does all that sound right?
Yeah, it's a bit confusing.
Apache 1.3.6 and up -- STOP pressed:
the code keeps on running until it tries to read from or write to the
socket. the moment this happens, the script will stop the execution, and
run cleanup phase.
I think it's the same under mod_perl and mod_cgi. Am I right?
> Are there still issues with doing this?
>
>local $SIG{PIPE} = sub { $aborted++ };
you do this because you want it to be mod_cgi back compatible? If not this
would be better:
END {
$aborted++ if $r->connection->aborted;
}
And if you catch the signal you should do something about it other than
incrementing the count, right? like exit()
> Then mod_cgi I'm still unclear on.
>
> The cgi application does receive the SIGPIPE... well it did 1/2 hour ago
> before I rebooted my machine. Now I can't seem to catch it.
> But, printing again after the SIGPIPE will kill the CGI script.
Well, it doesn't know that it was aborted before you try print something.
I guess the explanation in the guide is not clear enough and should be
revised, especially per Doug's reply... any volunteers?
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: problems with %Location inside perl-sections
On Mon, 12 Feb 2001, Marc Lehmann wrote:
> On Mon, Feb 12, 2001 at 08:48:57AM +0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
> > Looks like Apache doing stat() calls problem. Try to run the request under
> > strace(1) or truss(1). See:
> > http://perl.apache.org/guide/performance.html#Reducing_the_Number_of_stat_Ca
>
> this is with perl-status:
>
> [pid 14461] stat("/tmp/perl-status", 0xb3cc) = -1 ENOENT (No such file or
>directory)
> [pid 14461] stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=3505, ...}) = 0
> [pid 14461] open("/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
> [pid 14461] open("/tmp/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
>
> and this is the same as with /test when there is no /tmp/test. With an
> existing /tmp/test, I get:
>
> [pid 14460] stat("/tmp/test", {st_mode=S_IFDIR|0755, st_size=35, ...}) = 0
> [pid 14460] open("/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
> [pid 14460] open("/tmp/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
> [pid 14460] open("/tmp/test/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
>directory)
Seems OK to me. I cannot reproduce your problem on my setup. The only
difference I have is that I have 'Options None' so I don't get the
.htaccess lookup.
> > >$Location{'/admin'} = { ... };
> > >$Location{'^/admin'} = { ... };
> >
> > Again, what strace tells you?
>
> apache is stat()'ing the path as long as it can, i.e. until
> .../cgi-bin/printenv oder . (there is no /admin directory in my
> DocumentRoot).
>
> > You will see everything that Apache does
> > while looking at the output.
>
> I couldn't try with PerlTransHandler yet (since I seem to have left this
> out when compiling mod_perl), but my question is: does this also fix the
> problems I encounter? I am not concerned about speed here, but rather
> about correctness, namely that I need ^/admin which shouldn't match at all
> in a Location directive.
What happens if you don't use C sections and just a normal Apache
config? Also it's possible that you mix-up name spaces, so Apache gets the
wrong location matched. You can see the docs about that in guide's config
chapter or in Apache manual. If that's the problem.
> Thanks a lot for your reply!
>
> --
> -==- |
> ==-- _ |
> ---==---(_)__ __ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
> -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
>
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Help with Apache::SubProcess needed.
On Mon, 12 Feb 2001, Stephen Gailey wrote: > Help with Apache::SubProcess needed. > > I have tried the example for running a long duration task from Mod > Perl, as found in the performance tuning guide, but I get the > following error: > > [error] Can't locate object method "cleanup_for_exec" > via package "Apache" at > /usr/local/apachessl/handlers/wrapper_handler line 22 > > I am using the script right off the page and I have downloaded (from > CPAN) and installed SubProcess. any ideas? I've released a new version of the guide, but Doug didn't have a chance to release a new version of this module with a new function yet. Just apply this patch and recompile: -- SubProcess.xs.orig Sat Sep 25 19:17:12 1999 +++ SubProcess.xs Tue Dec 19 21:03:22 2000 @@ -103,6 +103,14 @@ XPUSHs(io_hook(ioep, io_hook_read)); } + +void +ap_cleanup_for_exec(r) +Apache r + +CODE: +ap_cleanup_for_exec(); + int ap_call_exec(r, pgm=r->filename) Apache r _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Antwort: Repost: Anyone using "virtual server" for mod_perlhosts?
> As many people understood I mean some kind of virtual host service, I > would like to restate my question. > > There are companies (Verio at least) offering a 'virtual machine' > running a virtualized OS. Verio is offering NetBSD and Solaris. They > have a seriouly large iron where many virtual machines run, each virtual > machine gets a share of CPU, HD and RAM resources, an at least an IP > address. > > In there is a full OS, and you get to be root for about $150 a month. you can get root for free as well :) > It's a cheap alternative to co-location, a middle ground between a good > virtual hosting service and owning a box. You can run your own MTA, > compile whatever the hell you want, etc, although they offer a bunch of > services out-of-the-box and have a lot of useful --if annoying-- cron > jobs rotating your logs, monitoring the temperature of your daemons, > feeding the dog and whatnot. > > Of course, you get to share resources with a bunch of other customers. > It seems a great environment to set up a low traffic / highly customized > server, like apache+mod_perl. Now, I know and understand the services > they offer, but I have never actually used one with mod_perl. > > Now, has anyone tried this services? Do I have to worry about anything? > Why didn't Stas list them in his article? -- they don't appear in the > Guide either -- Do they have a fundamental or practical flaw I can't > see? cauze I've never tried these and nobody submitted them to me. I've sent a request to the list something like 4 months before publishing the article, I've used all the information I've received. If you want something to be added to the list of ISPs, just send me/the list an email and I will add it. Please also check this guide's chapter http://perl.apache.org/guide/multiuser.html and send me anything you want to be added there. Thanks. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
