Re: httpd.conf problem.
On Fri, Oct 08, 1999 at 04:25:39PM +0200, Terje Malmedal wrote:
> Inside a section I want to configure mod_rewrite dynamically,
> this works:
>
> $RewriteRule = "/cgi-bin/printenv /cgi-bin/slave.pl [PT]";
>
> If I do this:
>
> $RewriteRule = "/cgi-bin/printenv /cgi-bin/slave.pl [PT]";
> $RewriteRule = "/cgi-bin/test /cgi-bin/slave.pl [PT]";
>
> the last RewriteRule will hide the first one.
>
> The following attempts to not work at all:
> push(@RewriteRule , "/cgi-bin/printenv /cgi-bin/slave.pl [PT]");
> push(@RewriteRule , "/cgi-bin/printenv" , "/cgi-bin/slave.pl [PT]");
> push(@RewriteRule , "/cgi-bin/printenv" , "/cgi-bin/slave.pl", "[PT]");
> $RewriteRule{'/cgi-bin/printenv'} = "/cgi-bin/slave.pl [PT]";
>
> Am I missing something obvious?
Have you tried using the 'L' flag (see Apache manual) this will stop
further processing, ie:
$RewriteRule = "/cgi-bin/printenv /cgi-bin/slave.pl [PT,L]";
$RewriteRule = "/cgi-bin/test /cgi-bin/slave.pl [PT,L]";
--
I've been dead before. - Captain Spock, Star Trek VI
Mike Hall <[EMAIL PROTECTED]>, ICQ: #37292579, http://www.riverside.org
System Administrator (MH993) (*nix, OS/2 certified - C, Perl, CGI hacker)
Re: httpd.conf problem.
On Fri, Oct 08, 1999 at 11:54:58AM -0700, Cliff Rayman wrote: > I've never used perl sections, but unless $RewriteRule is some magic variable, > the second assignment simply overwrites the first one. Sorry for my previous post, I see the problem now after re-reading things. At first glance I thought he was having different problems and suggested the 'L' switch. I've never done anything similar to what he's doing so I don't have a suggestion for that, sorry about any confusion, got to try and remember to fully read before replying :-) -- If I told you you had a beautiful body, would you hold it against me ? Mike Hall <[EMAIL PROTECTED]>, ICQ: #37292579, http://www.riverside.org System Administrator (MH993) (*nix, OS/2 certified - C, Perl, CGI hacker)
Re: Apache::Registry and -M
On Tue, Jan 11, 2000 at 05:18:00PM -0800, Jeffrey W. Baker wrote: > From my quick look at Registry.pm it looks like there's no way to disable > the feature where a script will be re-compiled if it changes on disk. > > Is this correct? > > This is a problem if I update both the main script, and modules used by the > script. For example, adding a new subroutine to a module and then calling > it from the main Registry script. The main script will be recompiled, but > not the module, so I'll get an undefinded subroutine called. > > I'm not using Apache::StatINC - the module isn't in the @INC path at startup. > > I'd like to be able to move the updated script and module into place and > either do a -USR1 restart or just wait for the Apache processes to go > through their normal life cycle. As is, it seems as if I have to bring > down the server, move in the updated scripts in, and restart. Not the most > graceful process. May be mistaken but doesn't RegistryBB skip the recompile checks and just compiles once ? Seem to remember it being 'bare bones' and didn't do the 'stat's and stuff. -- When she hauled ass, it took three trips. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: Apache::Request
On Tue, Apr 11, 2000 at 11:52:44PM -0700, John S. Evans wrote: > I saw (in the code) that there's one open file per uploaded file. That > should be fine. I just need to find out if they're getting closed > correctly. > > What is "lsof"? 'LiSt Open Files', its really a handy tool for diagnosing. I just happened to be setting up a new machine today and checked for the latest release to grab and install. Its available at 'ftp://vic.cc.purdue.edu/pub/tools/unix/lsof'. -- The results of your IQ test are back, they're negative. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: [OT] Proxy Nice Failure
On Sat, Apr 22, 2000 at 12:28:41AM +0300, Stas Bekman wrote: > > > I like the mod_proxy module in reverse httpd accel mode, but > > > am interested in having some nicer failure capabilities. I have > > > hacked in this kind of stuff before but was wondering if anyone > > > had any official patch for this kind of stuff. > Hmm, cool ideas folks. The problem is that you probably should ask for > this at the mod_proxy list if such a beast exists. Unless the authors of > the module are lurking around mod_perl list. Correct me if I'm wrong, I > like the idea and I like it to be implemented too :) I'm on the new-httpd list (as a lurker, not a developer :-). Any ideas, patches, help porting, etc. would be more than welcome on the list. Mod-Proxy is actually kind of in limbo, there are some in favor of dropping it and others who want it. I guess the code is difficult and not easy to maintain and thats why some would just as soon see it go unless someone steps up to maintain (redesign) it. There are some working on it and apparently it will survive in some form or another. Now would be a perfect time for anybody to get involved in it. -- Friends don't let friends use Windows. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
mod_perl 2.x/perl 5.6.x ?
I'm more of a perl end user and plead ignorance in actually understanding what goes on behind the scenes. In the process of considering upgrading to perl 5.6 and according to a recent message I see its going to be required for mod_perl 2.x anyways so I guess its a good time to start migrating in that direction. I was curious as to if there are requirements as to how perl should be built for this. I scanned through the archives as I seemed to remember some threads about this awhile ago, especially regarding threads and multiplicity, from what I can see it looks like -DMULTIPLICITY is going to be required ?, don't know about -DTHREADS, doesn't look like it though. Can anybody in the know, shed some light on this, just trying to save some work down the road as I'd like to upgrade to the perl 5.6 stuff now and use it with my existing mod_perl (I already use the CVS version and I know thats required for perl 5.6) but I really don't want to have recompile perl (and modules, etc) again later if I can build it the way it will need to be now and continue using mod_perl 1.x and then just upgrade to mod_perl 2.x down the road. Thanks, -- A person is not old until regrets take the place of dreams. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, Apr 22, 2000 at 11:59:58AM +0200, Eric Cholet wrote: > > though. Can anybody in the know, shed some light on this, just trying to > > save some work down the road as I'd like to upgrade to the perl 5.6 stuff > > now and use it with my existing mod_perl (I already use the CVS version > > and I know thats required for perl 5.6) but I really don't want to have > > recompile perl (and modules, etc) again later if I can build it the way > > it will need to be now and continue using mod_perl 1.x and then just upgrade > > to mod_perl 2.x down the road. > > mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns > on threading and multiplicity. The biggest hurdle I've faced until now is > that DBI won't build with this threaded perl. Hopefully DBI will be updated > since the latest version is from july 99. > This is for using Apache 2.0's pthread MPM, of course you can build perl > 5.6 non threaded and use apache 2.0's prefork model but then it's not > as exciting :-) Thinking about it now after your message and it makes sense. I've actually been a bit lazy and still have one of the older CVS versions (pre alpha) of Apache 2.0, guess I don't know about the alphas but I was playing with both the threaded, dexter MPM's. Since dexter is kind of a hybrid but uses threads I assume it'll also need a threaded perl then. At one time I did build a threaded perl but ran into problems here and there with various modules, etc. Don't recall having any problems with DBI but then again it wasn't perl 5.6 either, that is kind of a show stopper though :-( All in all I guess I found out the answer, might just as well go for it and build 5.6 threaded, grab the lastest Apache 2.x alpha and take what comes. Its my play box anyways so I guess I can live with some things being broken :-) -- Didn't I see your picture on a milk carton ? Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: mod_perl 2.x/perl 5.6.x ?
On Tue, Apr 25, 2000 at 07:08:00PM -0700, Doug MacEachern wrote: > > The biggest hurdle I've faced until now is > > that DBI won't build with this threaded perl. Hopefully DBI will be updated > > since the latest version is from july 99. > > it compiles with the patch below, not sure if it actually works though :) Just tried it here and aside from some warnings it compiled and passed all its tests. Can't say whether it works or not though as Msql-Mysql doesn't compile, you got a patch hiding for that somewhere too :-) PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ? -- I'm as confused as a baby in a topless bar. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: mod_perl 2.x/perl 5.6.x ?
On Wed, Apr 26, 2000 at 01:32:29AM -0700, Doug MacEachern wrote:
> > Just tried it here and aside from some warnings it compiled and passed all
> > its tests. Can't say whether it works or not though as Msql-Mysql doesn't
> > compile, you got a patch hiding for that somewhere too :-)
>
> sure :) again, just compiles, not sure if it works.
>
> > PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ?
>
> not at all, but i doubt either patch is quite right (the mysql one esp. is
> a quick hack)
Geez, I wasn't actually expecting a patch (just hoping maybe :-) and here
one is ! What can I say besides restating an earlier comment some else
posted recently "** You're the man **" !!
I don't know if the patches are quite right as you say, but both patches
(DBI, Msql-Mysql) compiled, passed their tests and after moving a couple
of scripts and databases over to the 'play' box they worked fine accessing
the mysql databases, displaying, inserting, and deleting records. Its just
a simple database-based GuestBook, nothing major but if its any indication
things appear to work fine with your patches.
I held off posting either of them to 'dbi-users' until I could do some
testing but since they seem to work I'm going to go ahead and post them
over there so the authors can take a peek, review, etc.
PS: I did find a patch Tim had posted for DBI, it didn't work for DBI but
it did work for Msql-Mysql. Looks like either your Msql-Mysql patch
or Tim's DBI patch work for Msql-Mysql, the common key seems to be
defining 'dbis', although they do it in different ways. I stuck with
your patches for both to keep things consistent. Tim's patch is below:
Index: DBI-1.1301/DBIXS.h
Prereq: 10.11
*** DBI-1.13/DBIXS.hMon Jul 12 03:04:28 1999
--- DBI-1.1301/DBIXS.h Tue Jul 13 23:01:22 1999
***
*** 1,4
! /* $Id: DBIXS.h,v 10.11 1999/07/12 02:02:33 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
--- 1,4
! /* $Id: DBIXS.h,v 10.12 1999/07/13 22:01:12 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
***
*** 397,407
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t * get_dbistate() {
! return ((dbistate_t*)SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (get_dbistate())
#else /* plain and simple non perl object / multiplicity case */
# define DBISTATE_DECLARE static dbistate_t *DBIS
--- 397,410
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t **get_dbistate() {
! return ((dbistate_t**)&SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (*get_dbistate())
+ /* temporary for drivers that mistakenly use 'dbis' instead of 'DBIS' */
+ # define dbis (*get_dbistate())
+
#else /* plain and simple non perl object / multiplicity case */
Re: [RFC] modproxy:modperl ratios...
On Thu, Apr 27, 2000 at 02:29:15AM +, [EMAIL PROTECTED] wrote: > Matt & List, > > Is there any benefit of mod_proxy over a real proxy front end like "Oops"? > > > > This is a good question..., the only answer I've come up with thus far > from reading the new-httpd devel list is compelling though. Here's > what people there said in response to folks trying to kill mod_proxy > as a canoniacle apache module: (Using the argument your sort of > alluding to) > 1) Using mod_proxy as opposed to a seperate package allows you to > leverage other apache modules..., mod_ssl, and mod_raven for > commercial folks comes to mind. > 2) Apache logging. It's the real deal. > > Those are the only two that I saw on the list that held any water with > me. However, if there is an async i/o frontend out there, it would > have distinct advantages over apache. Namely speed. But for me the > most compelling is reason #1. If I finish my async i/o patch to > mod_proxy..., to me, there would be no reason to contemplate another > package. (Clearly HUGE personal bias here) I'm with you. Setup Squid at one time and although it worked it did have some quirks and I didn't see any performance benefits (actually if I recall it was slower). I like the Apache way as its fairly straight forward (unless you get into some of the esoteric mod_rewrite stuff), everythings setup in one config, plus the benefits you mentioned above. > BTW: As Mike Hall brought up, they wanted to kill it because there is > no maintainer for mod_proxy. There are a lot of people Yes, recently people have been 'stepping up to the plate', quite a change from even a month ago, guess they realized its either do or die -- Marijuana is nature's way of saying, "Hi!". Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
OT: Re: Most nonesense I've ever read about mod_perl
On Sun, May 07, 2000 at 08:20:34PM -0400, Jeff Stuart wrote: > [...rest of message deleted...] > > Every language has it use, the truly knowledgeable understand when to > > use each language:) > > > Sam > Amen to that!!! I think that this point and the point about writing GOOD > algorithms are VERY important ones and I think that it's important that this > be taught! I'm not sure if it's being taught now in school but in my day > (GOD I sound old :)) (1987-1991) it wasn't. You make me sound ancient :-) When I started at the UofM (1971) it was Fortran 77, Pascal and punch cards. You're right though, not much on theory, algorithms, style, etc., just dry examples out of text books. Lot of good any of that does me these days, things like Perl, C, weren't around (or at least I never heard of them) and not much use for Fortran or Pascal these days, I guess it was still valuable for the experience though. -- The more you run over a dog, the flatter it gets. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: Bugs 5.6.0 modperl use?
On Fri, May 26, 2000 at 01:36:33AM -0400, Jeff Stuart wrote: > Ok, follow up question if I may. :) Are any of you using it with DBI and > DBD::mysql? I see on the Mason list that people are using it with > HTML::Mason so that module is safe. :) Looks like I'm gonna have to pull > out that old Linux box and do a test on it. :) Using DBI, DBD:mysql, and perl 5.60 (compiled with -DUseThreads) here. Doug was kind enough to post a couple of patches for DBI and DBD:mysql to get them to compile (when using -DUseThreads). I wouldn't call it a production server though since its very low volume, but I haven't had any problems with it. You can search the archives for 'Subject: Re: mod_perl 2.x/perl 5.6.x ?' to find the patches or email me and I'll send them. -- He was so crooked you could use him to pull corks with. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: Bugs 5.6.0 modperl use?
On Thu, Jun 01, 2000 at 12:00:45PM -0700, Doug MacEachern wrote: > On Fri, 26 May 2000, Michael hall wrote: > > > On Fri, May 26, 2000 at 01:36:33AM -0400, Jeff Stuart wrote: > > > > > Ok, follow up question if I may. :) Are any of you using it with DBI and > > > DBD::mysql? I see on the Mason list that people are using it with > > > HTML::Mason so that module is safe. :) Looks like I'm gonna have to pull > > > out that old Linux box and do a test on it. :) > > > > Using DBI, DBD:mysql, and perl 5.60 (compiled with -DUseThreads) here. Doug > > was kind enough to post a couple of patches for DBI and DBD:mysql to get > > them to compile (when using -DUseThreads). I wouldn't call it a production > > server though since its very low volume, but I haven't had any problems > > with it. > > did you forward those patches along to the authors? Yes, and also posted them on the 'dbi-users' list. Other than a few requests for them from others (which I sent them :-) I haven't had any response from either Tim or Joachim (sp?). Just installed a new Mysql-modules the other day, no changes I could see so I just applied your patch and compiled it otherwise it failed with the same old stuff. Tim posted a message awhile ago that there would be a new version of DBI coming out soon, hopefully it'll incorporate some fixes. -- Do I have to pee whenever I see this sign ? WET FLOOR... Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
Re: Apache::RefererBlock and ModuleConfig problem?
On Thu, Aug 03, 2000 at 01:27:17PM +0100, Matt Sergeant wrote: > On Thu, 3 Aug 2000, Geoffrey Young wrote: > > > you need to specify EVERYTHING=1 or PERL_DIRECTIVE_HANDLERS=1 to enable > > Apache::ModuleConfig, ie > > perl Makefile.PL EVERYTHING=1 > > make > > etc... > > Which raises an interesting question... Is there any way for Makefile.PL > to determin if a particular option was enabled at mod_perl build time? 'http://site/perl-status?hooks' ? -- I let my mind wander and it didn't come back... Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
