RE: Setting PerlRequire in a section
> > > I understood the limitation of the single interpreter, the > problem again > > was to append to @INC per VirtualHost. > > It's confusing when you say that, since there's only one @INC for > everything. I'm interpreting this as meaning that you have a bunch of > applications with different install directories and you want > them all to go > in the global @INC. Sorry for the confusion. Your interpretation is correct. I wish to add several different paths to the common global @INC, one per application. > How do you avoid hard-coding the paths to app.httpd.conf > then? If you're > already hard-coding that path on each server, you should be > able to just > make everything else relative to that. Is that what you were > trying to do > with your original post? That code would work fine if you change > $PerlRequire to a straight 'require'. They do the same thing. Exactly, the only abs path we would like is the per-server master httpd.conf. The difference (or lack thereof) between PerlRequire and require in a section wa lost on me. Thanks for the tip. > Well, what Stas was talking about with mod_perl 2 was just > having different > Perl interpreters (with different @INCs) per VirtualHost, > which actually > doesn't sound like it has much to do with your problem. Not directly, no it wouldn't, although I actually would like to see this for other issues we had earlier (which we solved by moving all our packages into unique namespaces). I'll look into the other configuration solution you mentioned, although I expect they provide more than we really need for these applications. Thanks, Alex
Re: [OT] New Micro$oft vulnerability?
I was able to change all the PerlSetEnv directives to SetEnv and all seems to be well. There was really no need to set the values so early anyway (since they're only being referenced during content generation). Thanx, Tim. On Fri, Sep 21, 2001 at 02:13:29PM -0600, Nathan Torkington wrote: > > Tim Peoples writes: > > I tried doing the s/OK/DECLINED/ thing and it didn't do the trick. :-( > > > > I forgot to mention that this is in combination with HTML::Mason, > > but I doubt that should have any effect. > > This appears to be a bug in mod_perl, partially (said, I think, Geoff > Young) fixed in the latest version but still not completely > eradicated. I was mistaken with the OK/DECLINED change--that doesn't > make PerlSetEnv work again. > > I don't have a workaround, sorry. I don't know exactly what triggers > the problem (is it PostReadRequestHandler, is it preventing logging, > is it a 408?) It might be that you could use a different phase of the > transaction, and work around it. Sorry I can't be more help. > > Nat -- __ \ \ Timothy E. Peoples \ c o l l e c t i v e Engineering Manager \ \ [EMAIL PROTECTED] Give a man fire and he will be warm for a day, Set a man on fire and he will be warm for the rest of his life.
Re: [OT] New Micro$oft vulnerability?
Tim Peoples writes: > I tried doing the s/OK/DECLINED/ thing and it didn't do the trick. :-( > > I forgot to mention that this is in combination with HTML::Mason, > but I doubt that should have any effect. This appears to be a bug in mod_perl, partially (said, I think, Geoff Young) fixed in the latest version but still not completely eradicated. I was mistaken with the OK/DECLINED change--that doesn't make PerlSetEnv work again. I don't have a workaround, sorry. I don't know exactly what triggers the problem (is it PostReadRequestHandler, is it preventing logging, is it a 408?) It might be that you could use a different phase of the transaction, and work around it. Sorry I can't be more help. Nat
Re: Setting PerlRequire in a section
> I understood the limitation of the single interpreter, the problem again > was to append to @INC per VirtualHost. It's confusing when you say that, since there's only one @INC for everything. I'm interpreting this as meaning that you have a bunch of applications with different install directories and you want them all to go in the global @INC. > The goal was to be able to checkout the application source from our CVS > repository, "Include" its "app.httpd.conf" from the main httpd.conf, and > be ready to go, with the absolute path for each application's lib > directory appended to @INC for StatINC to work. How do you avoid hard-coding the paths to app.httpd.conf then? If you're already hard-coding that path on each server, you should be able to just make everything else relative to that. Is that what you were trying to do with your original post? That code would work fine if you change $PerlRequire to a straight 'require'. They do the same thing. my $dirroot = $0; $dirroot = s/\.htaccess$//; require ($dirroot . 'modperlstartup.pl'); > As I mentioned previously we switched to absolute paths in the > per-application startup.pl file. Its a pain to maintain a per-server > times per-application list of lib paths, but that fixes us until I get > to see what mod_perl 2.0 has in store for me :-) Well, what Stas was talking about with mod_perl 2 was just having different Perl interpreters (with different @INCs) per VirtualHost, which actually doesn't sound like it has much to do with your problem. I still don't understand what problem you're trying to solve well enough to give good advice, but configuration management issues are commonly handled through an installation process that sets local paths. The last time I had to do that for a mod_perl app, we used Template Toolkit to generate our httpd.conf and startup.pl with local paths during the install. For simpler localization, you could just use a couple of substitutions, or you could try playing with MakeMaker. - Perrin
RE: Setting PerlRequire in a section
I understood the limitation of the single interpreter, the problem again was to append to @INC per VirtualHost. For example, Application A: running on server 1 has its lib directory at /data/appA/lib/. Its lib packages are in namespace "AppA::" (to prevent overlap in the single Perl interpreter). Application B: running on server 1 has its lib directory at /opt/appB/server/lib. Its lib packages are in namespace "AppB::". The same applications when deployed on server 2, might or might not have the same absolute path to their lib directory. So, for example AppA's lib on server2 might live at /data4/servers/AppA/lib. The historical reason for the differences in path aren't important, just assume I can't fix them :-). Since all app's are segregated into namespaces for their packages, a single interpreter is OK, there is no overlap (we made that change specifically to support mod_perl). The goal was to be able to checkout the application source from our CVS repository, "Include" its "app.httpd.conf" from the main httpd.conf, and be ready to go, with the absolute path for each application's lib directory appended to @INC for StatINC to work. Obviously in order for that to work each App's startup.pl would need to be able to determine its path as it is PerlRequire'd, so it can build the needed path to the lib directory. Wihtout FindBin this doesn't work under mod_perl. sections appeared to be capable of doing it (since the app.httpd.conf was located in the source tree of the app we could use $0 to find the path to app.httpd.conf) but attempting to do too much in a section seemed to constantly cause breaks (I eventually gave up). As I mentioned previously we switched to absolute paths in the per-application startup.pl file. Its a pain to maintain a per-server times per-application list of lib paths, but that fixes us until I get to see what mod_perl 2.0 has in store for me :-) Thanks again for all the responses, Alex > -Original Message- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 21, 2001 8:06 AM > To: Alex Harper; Stas Bekman > Cc: [EMAIL PROTECTED] > Subject: Re: Setting PerlRequire in a section > > > > Actually, yes, I had. PerlVINC is not really what I needed, > the goal was > > not to reload %INC per VirtualHost, the need was to have a single > > PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC > > would work). Ordinary this would have been done with > something like 'use > > lib "$FindBin::Bin/lib/", but since that doesn't work under > mod_perl I > > was toying with using sections. > > It sounds like maybe you were not understanding that in the > mod_perl 1.x > series there is only 1 Perl interpreter shared between all > VirtualHosts > (they are virtual, after all). That means there can only be > one @INC for > all VirtualHosts as well. Things like PerlVINC cheat by > messing with @INC > on each request. > > - Perrin > >
Re: Setting PerlRequire in a section
> Actually, yes, I had. PerlVINC is not really what I needed, the goal was > not to reload %INC per VirtualHost, the need was to have a single > PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC > would work). Ordinary this would have been done with something like 'use > lib "$FindBin::Bin/lib/", but since that doesn't work under mod_perl I > was toying with using sections. It sounds like maybe you were not understanding that in the mod_perl 1.x series there is only 1 Perl interpreter shared between all VirtualHosts (they are virtual, after all). That means there can only be one @INC for all VirtualHosts as well. Things like PerlVINC cheat by messing with @INC on each request. - Perrin
